Ask Slashdot: Making JavaScript Tolerable For a Dyed-in-the-Wool C/C++/Java Guy? 575
DocDyson writes "I'm a dyed-in-the-wool C/C++/Java developer with over 20 years of experience. I'm making a good living and having fun doing back-end Java work right now, but I strongly believe in being a generalist, so I'm finally trying to learn the HTML5/CSS3/JavaScript future of the Web. However, I find JavaScript's weak typing and dynamic nature difficult to adapt to because I'm so used to strongly-typed, compiled languages with lots of compile-time error-checking and help from the IDE. Does anyone out there who has made this transition have any tips in terms of the best tools and libraries to use to make JavaScript more palatable to us old-school developers?"
Not an Old-School Problem (Score:4, Interesting)
Why? (Score:4, Interesting)
Seriously, find something else to do... (Score:4, Interesting)
JavaScript can do amazing things, but it's a total disaster if you're coming from a more traditionalist background.
Let me give you a taste of what's to come for you :).
Let's say you have an Applet/ActiveX Control/Plugin of some type that your company has built and needs to be scriptable from JS, and it must also be able to call into JS (JavaScript devs can register for events, notifications, console/logging messages, et cetera...)
You add a new feature to your Company's doohickey. Now you need to test it properly.
Your customer set requires that you need to test on OSX Snow Leopard, OSX Lion, Windows XP, Vista, Win 7, OpenSUSE, Redhat, and Ubuntu. On each of these operating systems you need to test on the most popular browsers, so you get jiggy with Safari, Firefox, Opera, IE7, IE8, IE9, Konquerer, et cetera... Then you, depending upon the plugin's architecture, need to test on both 32-bit and 64-bit versions of the plugin in each browser on each operating system.
That's not even getting started with Mobile, or JRE versions, or different deployment types, code signing, et cetera, ad nauseum, ad infinitum.
If you think you don't need to test like that, you're in for a rude awakening my friend... For example, this very testing led to our discovering that in Firefox, on Windows 7 rapid LiveConnect usage between an Applet and JavaScript is perfectly fine if the applet has focus, or another windows has focus, but causes total freezing of Firefox/Java Plugin IF THE FOCUS GOES TO ANOTHER ELEMENT ON THE SAME WEB PAGE. How's that for crazy sh**? :) LOL.
Anyhow.
Browser application development is a nightmare.
I would pay good money for them to rip JavaScript out and everyone get together (yeah, I know, pipe dream) and come up with a client side scripting language that rocked oldSk00l.
Perl (Score:4, Interesting)
Learn Perl first. Or maybe LISP. That way you'll get rid of the statically-typed mindset. :)
Java/ECMAscript is Perl/Python in C++/Java clothes. Don't even think about C++ or Java. It doesn't work that way.
Re:Know the language, practice safe coding (Score:4, Interesting)
I think he's basically asking for jslint, where you can catch errors many levels deep in your code at compile time, rather than waiting for the code to crash when it, eventually, gets run (in unit test or whatever).
Re:Javascript: The good parts (Score:3, Interesting)
Take Douglas Crockford's advice: "JavaScript is Lisp in C's clothing."
Re:Going down in flames (Score:5, Interesting)
Use Google's Closure Compiler in ADVANCED_OPTIMIZATIONS mode. It reads various JSDoc hints, and can provide compile-time warnings and errors when you violate type constraints. It doesn't exactly make JavaScript strongly typed, there are a variety of ways you could fool it if i you want, but you'll be writing TIGHT JavaScript code that would be the envy of most web developers. And it'll out-perform anything they can produce because of the additional compile-time optimizations it can offer.
It's part of our build process here now. All JS scripts have to go through Closure. Unfortunately a number of 3rd party libraries won't work in advanced optimizations mode, so we can't use advanced across the board, but those scripts where we control the source, we get substantial size and performance gains, as well as the sanity of a compiler looking over our shoulder making sure we don't make a variety of humdrum simple mistakes.
You also get the advantage of being able to use compiler flags to alter the compiled source (@const declarations are replaced inline, and you can override the value of an @const at compile time, so you can have the equivalent of IFDEF's for different code paths per browser, and so forth - dead code paths are trimmed by the compiler so they don't increase the size of the output or have any performance impact for the end user).
Re:Any rational programmer is anti-JS (Score:4, Interesting)
Re:Going down in flames (Score:5, Interesting)
There used to be a great debugger called the Venkman debugger. Actually its still around , but more and more I just use firebug.
If your doing web, here are your main tools. webdeveloper toolbar & firebug. webdeveloper toolbar has a bunch of useful widgets like screen rulers and stuff, and firebug lets you poke under the hood of a page , run queries against the javascript , look at the calculated values of various DOM properties and so on.
You also NEED to aquaint yourself with jquery. Javascript is almost untolerable without it. Jquery provides an xpath-ish interface to getting at the dom and utilizes lots of anonymous-closure goodness (dont fear it, embrace it, its good) to let you build up fairly complex behaviors quickly.
You'll probably want a good whiskey supply to drown your sorrows after knock off time too. Javascript is bloody awful.
Re:Going down in flames (Score:1, Interesting)
You also NEED to aquaint yourself with jquery. Javascript is almost untolerable without it.
Ugh. No you don't. Run as far away as you can from that and the zillion other steaming-piles like it (underscore.js comes to mind here).
If you've ever asked yourself "how can I make my code less readable?" or "how can I over-complicate this simple problem?" then jquery is your answer.
You'll probably want a good whiskey supply to drown your sorrows after knock off time too. Javascript is bloody awful.
Stop using jquery and you'll find that half of your headaches are gone automatically. Javascript can brain-dead simple if you know how to use it -- and it can be a gigantic headache when you use it incorrectly. If you think jquery makes your life easier, you're clearly using it wrong.
Re:Your are clearly too rational to be here... (Score:5, Interesting)
Programing languages are tools. The only objective comparison for tools is the
objects they can produce; programs.
So to objectively compare programing languages you must compare programs
that do exactly the same thing but are written with different programing languages.
Now how easily would you create an asynchronously interactive web site
without javascript and how would it perform?
Re:Going down in flames (Score:3, Interesting)
but after many years developing with dynamic languages, I will tell you that mismatched-typing issues are a tiny minority of bugs I've seen make it to production.
I couldn't agree with you more here
Once upon a time, type theorists said 'use strong typing and the compiler can generate better code because it has more known invariants!' Then the StrongTalk team showed that a decent compiler could infer better type information via type feedback than the user specified with explicit annotations. So the type theorists said 'use strong typing, because you'll have fewer bugs!' Then someone pointed them to the proof (which is actually well within the realms of undergraduate mathematics) that you can't prove any nontrivial property of a program using type theory. Then the type theorists started to become quiet and only the type theory fanboys kept talking about strong typing as if it were a good thing.
Now of course, we have Category Theory, which will definitely deliver all of the things that Type Theory promised to deliver. Honest!
Re:Going down in flames (Score:5, Interesting)
Simple: clear, debuggable, logically organized, and debuggable code.
Don't define functions inline of your statement.
Don't perform evaluations in your return statements.
Avoid calling methods/functions on objects via the return of another evaluator.
The code sample he provided is counter to reusability, readability, unsafe in that it doesn't evaluate possible nulls, and arguably impossible to debug.
It has nothing to do with being a JavaScript guy or not. It has everything to do with the difference between being a programmer and a software engineer. They are two different things.
Re:He wants Google Web Toolkit (Score:5, Interesting)
JS's problem is not dynamic typing, it's that it is not strict enough. If you try fetching a property or method that doesn't exist on an object in Python or Ruby, which are dynamic languages, you get a runtime error. In JavaScript you get undefined, in Lua you get nil. But even Lua doesn't allow you to do freaking *arithmetic* on nil, and fetch arbitrary properties on numbers and strings. In JavaScript, undefined + 0 is valid and yields NaN, and then you can happily keep operating on that value until you crash and burn. And then you can do {} + [], giving 0, and [] + {}, giving "[object Object]". It is ridiculous. All of these additions should be errors, plain and simple, and ideally, x.y, when y is not a field of x, should be an error. Maybe x.?y and x[?y] could return undefined or nil in these situations, as a handy syntactic sugar.