Slashdot Mirror
Ask Slashdot: Making JavaScript Tolerable For a Dyed-in-the-Wool C/C++/Java Guy?
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?"
Why bother making the transition? You're background sounds like mine - C, C++ then Java - and based on a few years of dealing wih Perl I'd never willingly use a weakly typed language. Many errors in statically typed languages can be caught by the compiler, static analysis tools or nowadays by the IDE. Whereas with crap like Perl, JavaScript or *spit* PHP, such tools are hindered by the language and often by the libraries to the point where you'll drown in warnings that may or not be of genuine concern. In short, your existing skills are in demand, so leave the crap languages to the script kids.
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).
Slay a dragon... over lunch!
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.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
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?
-- no sig today
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.
Loading...
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.