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?"

Comments

Going down in flames

[Anonymous Coward]

Probably gonna get flamed for this, but my advice.. don't fight it! When in Rome.. etc.

Javascript isn't meant to be done like c++ or Java, so don't try! Think about the mess you get when an assembly guy tries his hand at Java. It's the same deal. It's a whole different mindset, and if you fight it you'll just end up with a big mess and a lot of wasted time.

That said, some stuff does transfer over. You can still go through proper requirements, design and testing. Basic principles like encapsulation and reuse still sorta apply (and are highly recommended imo). Before doing anything that seems like a common use case, check to see if someone has already done it (but don't blindly use it.. a lot of really shitty stuff out there.. but some gems too!).

Re:Going down in flames

[Anonymous Coward]

Moving from assembly to Java is a big jump because you're gaining many abstractions that just don't exist in assembly, and giving up some some concreteness that just isn't as useful in Java.

The exact opposite happens when you move from Java or C++ to JavaScript, and this is what the submitter is suffering from. JavaScript has inferior abstractions compared to what Java and C++ offer. The submitter feels pain because he's apparently an experienced programmer who knows that he's losing many valuable tools when using JavaScript, and getting nothing beneficial in return.

Just look how stupidly difficult it is in JavaScript to implement even basic inheritance. There are many different ways, and they are all horrible. Java and C++ both make the definition of classes and inheritance hierarchies extremely simple and easy. It's far easier to imitate JavaScript's prototype-based OO approach in Java or C++ than it is to implement rudimentary class-based inheritance in JavaScript.

JavaScript advocates usually toss out something about "lambda functions" or "closures" at this point. Well, it turns out that they can both be implemented very easily using the proper class support that both Java and C++ offer. Nevertheless, C++11 currently offers some syntactic sugar to make lambda functions easier to work with, and Java 8 will likely support an even easier lambda syntax, as well.

This is all ignoring the other major problems the submitter highlighted, too. You don't have a compiler doing a lot of type checking automatically when you're using JavaScript. So you have to accept that these errors will be caught by the end user (and they always will be), even if you put in a lot of manual effort basically implementing type checking yourself within your JavaScript code. Then there are the lack of proper IDEs, good debuggers (Firebug pales compared to a real C++ or Java debugger), and the many other tools that a C++ or Java programmers expects to use.

My advice to the submitter is for him to lower his standards significantly. It'll be painful, but that's the only way to stay sane when using JavaScript. Expect poor results from the language you're using. Expect poor results from the libraries you're using. Expect poor results from the runtimes (browsers) you're targeting. Expect lower-quality software. Expect more end-user complaints. Oh, and welcome to web development.

Re:Going down in flames

[Anonymous Coward]

The most telling thing about JavaScript as a language, and the community that surrounds it, is that the most widely-respected book is "JavaScript: The Good Parts". It's a book that basically tells you what parts of JavaScript never to use!

Compare this to the most respected books about other programming languages. I'm talking about "The C Programming Language" for C, "The C++ Programming Language" for C++, and even "Programming Perl" for goddamn Perl. They're the complete opposite. They explain each and every feature the language offers, and how to use them effectively.

Something is seriously wrong with a programming language when the most useful books about it are those telling you to not use large portions of the language!

Re:Going down in flames

[nahdude812]

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:Going down in flames

[chooks]

If closures and lambda expressions were so easy to implement using basic inheritance, Java would already have it. Java 7 has no lambda structures or closures. Anonymous inner classes are a hacked on incomplete poor mans semi-closure that provides just enough to get you almost what you want, but not quite. Last I checked, JCP (or related) had this as a work in progress. And will it be a first class construct in Java or some kind of pre-compiler/interpreter/VM? I am not sure, but hopefully the former.

Java makes many things easier, but functional programming constructs is not one of these. Once I (re)learned how to use the more functional approach (it has been a long time since my LISP days) I really started to (re)appreciate the power of it. Some may wax poetical about elegance, simplicity, etc.. but that is really what it felt like to me. It sure made it harder to swallow some of the limitations that Java has without these constructs.

I am definitely not a javascript fanboi, and absolutely agree with you (and the 1E6 others) that hate the toolset for developing with it, but I do appreciate the programmatic constructs it allows. And these constructs are definitely not in Java yet (cause boy, could I have used some of them on my last project!)

Re:Going down in flames

[defcon-11]

"JavaScript has inferior abstractions compared to what Java and C++ offer" As someone who codes in both Java and JavaScript, I find Javascript much more flexible, and closer to a true OO language, as opposed to Java's sort-a-kind-a OO. Javascript has several well known design flaws, but so does Java. The flaws are generally well known, and experienced programmers form either language shouldn't have a problem avoiding them. Most people that I've worked with and who complain about Javascript haven't taken the time to learn how the language works, and instead just try to impose class based OO, which always fails miserably. When using a prototype OO language (Javascript, Python, Ruby), OO principles such as 'interface composition instead of inheritance' that Java developers praise suddenly become much easier to apply without resorting to design patterns aimed at getting around Java's lack of multiple inheritance, or other shortcomings. Java's type checking can be helpful at times, 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.

Re:Going down in flames

[ozmanjusri]

Lack of a good debugging and testing environment is the only reason Javascript is goddamn annoying.

Eclipse/Aptana, Webstorm or Netbeans are all good IDEs that handle debugging either natively or with plugins.

Re:Going down in flames

[cshark]

My advice to the submitter is for him to lower his standards significantly. It'll be painful, but that's the only way to stay sane when using JavaScript. Expect poor results from the language you're using. Expect poor results from the libraries you're using. Expect poor results from the runtimes (browsers) you're targeting. Expect lower-quality software. Expect more end-user complaints. Oh, and welcome to web development.

I'm really tired of hearing xenophobic morons complain about languages and tools they don't understand, and spouting off the same nonsense that hasn't been true for years. It doesn't bode well for your understanding of any language when you're readdressing grievances that were resolved a decade ago. Get your head out of your ass, and get with the times, please. Here's the deal: Just because you don't understand it, does not make it an infirior, low quality language. Just because you're incapable of writing code that performs well, does not means that the language is slow or sluggish. It simply means you're a closed minded idiot who refuses to learn the basic principles, ideas, and uses behind the thing.

You can't compare Javascript to C++ or Java. Not only is it a totally different mindset, but it's a totally different use case. In Java and C++ you're writing libraries and interfaces. In Javascript, you're writing libraries and documents. Documents are fundamentally different than interfaces because the structures are different. Javascript is a means by which to manipulate a web page. In practical terms, nothing more. Javascript is out of place on server side, which is why server style Javascript has never caught on, and it doesn't really make a lot of sense as a general purpose programming language either.

To date I've met a lot of C++ programmers that have tried Javascript. I've only known one who was any good at it, and none of them have been better at it than me (which is generally how I evaluate other programmers, generally). It's not a bad thing. It is what it is. C++ and Javascript are so different, that there's really no way to do an apples to apples comparison. And, it's probably easier to go from something like Javascript to C++ than it is to go the other way.

If you're going to go from C++, just put the whole thing out of your mind, and pick up something hands on. If there's a Hard Way book on the subject, it would be a good place to start. Also, picking up other scripting languages like Dart, PHP, or Python might get your brain to soften up a little. After spending time in C++ world, where you have to have absolute control over every aspect of everything you develop, going to Javascript where you really only control the DOM can be jarring. The hardest thing to do is just accept that Javascript is nothing like C++, and the tools that you're used to in and for C++ don't work for a reason.

As far as debugging tools. Don't bother with Chrome. It's nearly worthless for Javascript testing or debugging. Get yourself a copy of the latest Firefox stable, download Firebug, and the Web Developer Toolbar. Make sure you have at least a basic understanding of CSS 2 and its basic properties before attempting to do anything, and get yourself a copy of Netbeans. It has the best debugger, and the best reference material, in my opinion. It also has built in support for Subversion and CVS, which I find useful. Don't write anything in Javascript without version control. You'll thank me for that.

When you're first getting started, don't try to become an expert in Jquery or YUI. Learn the real thing first, and write something challenging from scratch. Since you're a C++ programmer, there are any number of things, I'm sure, that you can think of that would be fun to write in Javascript. When I learn a new language, I like to write an e-commerce program start to finish in it. If I were just starting with Javascript, I would attempt to write something for mobile. Mobile has the extra challenge of writing something useful, that maintains a smaller footprint. It'll kill your C++ tendencies flat. Or, it'll frustrate the hell out of you.

Either way.
Take Care

Re:Going down in flames

[Anonymous Coward]

Heh... the idea that you would be using every part of C++ and that all of it was good... brought a smile to my place. First of all, C++ is so large a language that practically no one knows everything about it. Second, books like "Effective C++" are precisely about the specific way to use selected features of C++ in order not to get bogged down later on.

Re:Going down in flames

[sg_oneill]

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

[dorward]

There are 14 pages giving the author's opinions about the parts of the language he doesn't like. The book is a lot longer than 14 pages.

Your copy appears to be missing most of its chapters.

Re:Going down in flames

[styrotech]

I agree with your post, but just have to point out that Ruby and Python are actually class based rather than prototype based like Javascript is.

Re:Going down in flames

[justforgetme]

I have learned to program in about a dozen programming languages over the years plus many frameworks for some of them. I can;t claim to be proficient (or efficient) in all of them but what I can claim is this: The only languages/frameworks I have no headaches about are the ones I have drilled down on and put an effort into understanding at the most involved level they allow.

In most cases it's not the language but the attitude/predisposition that creates problems.

Re:Going down in flames

[elp]

Jquery is simple to use and "just plain works"(tm). Trying to manage ajax queries on multiple browsers or work the DOM yourself sounds way too much like advanced masochism to me.

Re:Going down in flames

[somersault]

If you think JQuery overcomplicates things, maybe you're using it wrong?

The whole idea of having to put browser-dependent fixes into my JavaScript was what turned me off of doing any fancy UI stuff for a long time. I first looked at it around 2002 and was sickened by the whole incompatible browser DOM mess such that I didn't look again for years. Having all that crap hidden away behind JQuery helps to make it almost like "normal" programming again. Though even then there are still things that IE messes up..

If you feel that JQuery is making things less readable, why not wrap the JQuery stuff in your own functions? That's what I did for the AJAX functionality that I've built up.

Re:Going down in flames

[julesh]

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.

Sorry. I cannot agree here. Jquery enables some of the most elegant web programming I have ever seen. It allows, among other things, almost total separation of program logic from content -- I can use an entirely declarative approach on content elements that I want to be active, and then have a separate .js file to hook up the declarations and the actual logic behind them, trivially:

$(".hideable").before(function () {
    var hideableElement = this;
    return $("#showhidecontrol").clone().click(function () { hideableElement.toggleClass("hidden"); })});

(doing this from memory, untested, but I'm pretty sure it'll work)

Do that in three lines of code without jquery or another of the libraries you claim to despise. Hell, do it in 30. For reference -- it finds the element with id 'showhidecontrol' from the existing document and places deep copies of it before each element with class 'hideable', adding an onclick event handler to it that adds the class 'hidden' to the element with class 'hideable' if it isn't already present, or removes it if it is.

Re:Going down in flames

[dave420]

But jQuery has done wonders to make cross-browser JS coding ridiculously easy. You can use only the parts you want, such as the ajax stuff, and use them however you want. I don't know why you're so butt-hurt by it - did it touch you inappropriately? :)

Re:Going down in flames

[narcc]

Working with the DOM yourself is painless if you understand it. Most people don't (yet assume that they do) and haven't even made a legitimate effort to learn about it. If you read the standards, and spend some time playing with what you're reading about, you'll find that it's not difficult at all. You'll also find that managing cross-browser compatibility is almost as simple as merely avoiding a (vanishingly) small subset of things.

As for cross-browser ajax, it's also really easy *if* you've taken the time to actually understand it. I wrote a small cross-browser php/js ajax library years ago (2006 or 2007) that works (it's in production) unmodified to this day. It took less time to write than it did to learn the equivalent bits of jQuery.

jQuery, in my experience, leads to less-readable and less-maintainable code. The added bloat is just salt in the wound. Really, the people I see push hardest for jQuerey are the same people who don't seem to 'get' that JS is not Java/c#/c++ or people that don't really understand the DOM or CSS.

Sure, if you were tasked with creating a set of standards for the web you'd never come up with a mess like HTML, CSS, JS -- it's not difficult to imagine a simpler set of standards. Of course, it's what we have. jQuery just makes an already big mess even bigger -- with no obvious net-benefit.

Re:Going down in flames

[narcc]

That makes my point, doesn't it? It's non-obvious what the code does, even if you're familiar with jQuery.

To really understand it, you need a practical knowledge of jQuery, html, css, and ... (wait for it) ... the hard parts of javascript that you're trying to avoid learning about and using in the first place!

(Oh, and if you let me make my own versions of the before and toggleClass functions I can do that in javascript in well under 30 lines of much more readable code.)

Re:Going down in flames

[psmears]

It's non-obvious what the code does, even if you're familiar with jQuery.

It's clear enough to me (not a jquery expert by any means, though I have used it before now), though perhaps I'm more used to that style from other environments I've used in the past.

(Oh, and if you let me make my own versions of the before and toggleClass functions I can do that in javascript in well under 30 lines of much more readable code.)

Could you post it? I'd be very interested to compare the two styles :)

Re:Going down in flames

[Tsingi]

If you think jquery makes your life easier, you're clearly using it wrong.

That doesn't make any sense. Aside from that I agree with you. I don't use jQuery either.

Javascript is an extremely powerful language. The problem you have coming from c, c++ and (ugh) Java is that these languages are strictly typed and Javascript lets you do whatever you wish. A few weeks ago I made a statement that JavaScript was like c in that you had the power to soundly shoot yourself in the foot. Then I took it back. You can still do more damage with c.

First thing you have to do is learn what can be done in JavaqScript, then, you have an OO background, apply OO principles in your design and stick with them.

A few points:
- create a heirarchy mechanism and use it.
- global variables are BAD in javascript, I try to keep it down to one and have everything that isn't local belong to it.
- use jslint, javascript is horrible at telling you where problems are (like a missing semicolon)

I currently program in c, Python and JavaScript. Because I'm building web interfaces, but I am fluent in C++, Java, Perl, Lisp, assembly and a host of others. Except for Perl, which is the dogs breakfast, each of them have qualities that I like.

JavaScript is an interesting and powerful language. It does NOT hold your hand.

Re:Going down in flames

[Terrasque]

I found it rather readable, but then I'm used to jQuery. I would have formatted the code a bit differently to make it even easier to read, tho.

$(".hideable").before( function () {
        var hideableElement = $(this); // "this" is a raw element, we want a jQuery wrapped one
        var newToggleElement = $("#showhidecontrol").clone();
        newToggleElement.click( function () {
                hideableElement.toggleClass("hidden");
        });
        return newToggleElement;
});

Re:Going down in flames

[parkinglot777]

I cannot completely agree with you about JQuery that it is extremely good (or bad). The library attempts to formalize one and only one syntax for all browsers while shorten the script (condense each popular functionality into a separated function). In other words, it attempts to create a set of functions to replace the original lengthy script while developers can ignore what script is working and not working on different browsers. However, the problem is that many people rely on "library" too much, so they do not try to learn the "behind the scene" part. Before picking up a JS library, one should learn what the basic of JS first. This knowledge will help the one to understand what library is doing. From then, it will become easier to understand the format and functionality of the library.

Re:Going down in flames

[TheRaven64]

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

[TheRaven64]

To date I've met a lot of C++ programmers that have tried Javascript. I've only known one who was any good at it

To be fair, meeting a C++ programmer who is good at C++ is also pretty rare...

Re:Going down in flames

[Assmasher]

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:Going down in flames

[Assmasher]

Why not?

Well, it is unsafe, is anti-reusability, unclear, and impossible to debug without rewriting it to see why it doesn't work or suddenly stopped working. Defining a function inline to your statement, and in that function performing evaluations in your return call that are based upon objects that may be null when you execute an operation on them?

There's no need to go verbose for verbositys sake, and that piece of script is pretty neat.

There is a need to go verbose for the sake of everyone else who may ever have to work in the same codebase.

If you place a completely green web-developer in front of it, sure, he might have a hard time reading it, but if jQuery is a tool you use, and webdevelopment what you do, then this really shouldn't be much of a problem at all.

I'm not trying to denigrate you in any way, but this type of attitude is the difference between programming and software engineering. It is the discipline to do extra work that is tangibly less fun than doing clever or fun things.

I don't enjoy long variable names.
I don't enjoy modified Hungarian notation.
I don't enjoy seeing an obfuscating and clever way to manipulate something but then do it a more plodding and clear (if equally efficient) way.
I enjoy software architecture, but I don't enjoy writing up the design.
I don't enjoy the ridiculously long meetings involved in matching up the design to the spec to the requirements.
I don't enjoy putting in long comments to make absolutely sure someone coming in to fix a bug in the future is aware of the caveats of the possible changes they could make.

I do these things because I need to do them for the sake of the codebase/product/Company/Investors.

Re:Going down in flames

[elrous0]

If you're developing for the web, I've also found that Firefox has pretty good javascript debugging built in (go to tools: web developer: error console). Not as good as a full IDE, but a lot better than trying to do it manually.

Re:Going down in flames

[sg_oneill]

Dude, stop trying to use jquery as an OO tool, and use it as a functional programming tool and it'll make a lot more sense.

jquery is a monad. Treat it that way, and you'll see its a very elegant tool for dealing with whats ultimately a retarded underlying language.

Re:Going down in flames

[narcc]

The OP has a good question about the best way to use Javascript to facilitate classes and object-oriented design, but instead it's turned into a troll fest for people who are too rigid to understand the defacto industry standard paradigm for the web, simply because it's so different from the languages they work with.

First of all, objects in Javascript are prototype based, not class based. The OP has already set themselves up for failure. OOD isn't even a real thing -- like OOP, no one knows what it *really* is but they're all 100% sure that it's the best thing to happen to programming ever and that other people simply don't know how to use this methodology that "makes everything easier". (The first time I saw a factoryfactory I almost threw-up. I saw a factoryfactoryfactory the other day -- WTF was that idiot thinking? GoF has ruined an entire generation of programmers with their idiotic nonsense, and likely caused billions of dollars in lost productivity.)

Anyhow, if you really think selectors are essential, you really need to re-think your approach. Further, if lack of a standard document.getElementsBySelector() is the only reason you're using a bloated "framework" like jQuery, you can find smaller equivalents online or roll-your-own if you so choose. Either way, you'll be much better off.

Javascript is simple. Working with the DOM is simple if you understand it, which it seems most people don't, if this discussion is any indication.

A language that compiles to JS

[wisnoskij]

You could try a language that compiles to JS/etc.
My friend uses HaXe for all of his server development (http://haxe.org/doc/why).

Re:A language that compiles to JS

[tomk]

Unfortunately this is a great way to have to learn two languages (HaXe and Javascript) instead of one. I believe browser support for "source-level" operations (debugging, profiling, etc) for compile-to-JS languages will come some day, but that day is not today.

Re:A language that compiles to JS

[mihajul]

On the topic of languages that complile to JS, GWT is very nice, especially if you're using a Java back-end.

Re:A language that compiles to JS

[Ken_g6]

Indeed, this sounds like it makes a lot of sense. I recalled a Python to JavaScript compiler ("Pyjamas"), googled for it, and found an entire GitHub page of links to such compilers. It includes compilers for Python, Ruby, C#, C, and more. Heck, there's even one for Perl!

The only problem is I haven't tried any of these, so I have no idea how good they are. On the other hand, I have used some pretty bad language converters. (Many of which I wrote on the spot, but still...)

Re:A language that compiles to JS

[Derek Pomery]

https://github.com/kripken/emscripten

w/ emscripten, if you can output llvm from your language, you can run it in javascript.
Emscripten author claims 2-3x of optimised C.

Re:A language that compiles to JS

[Belial6]

That would contradict the point of his request. The only real answer is the first one given. Don't try to make it what you know. If you want to have skills in a language, learn the language. I could say that I can write code in Machine Code because my because my C compiler outputs machine code, but that doesn't make it true. If DocDyson learns HaXe and compiles to JS, he doesn't know JS he knows HaXe. His request for a good IDE is a valid one. His request for some good libraries that will smooth the learning curve is valid. A request for libraries that will make JS more like C is not valid, as it will not only prevent him from actually learning JS, but it will be useless in an environment that he doesn't have primary control of. If you want to be competent in JS, you have to learn the JS way.

Re:A language that compiles to JS

[Unoriginal_Nickname]

Seconding this as hard as I possibly can. GWT is honestly one of the nicest GUI libraries I've ever used, without even considering how nice it makes web development. I love GWT and I use it for everything web-related unless a client is really twisting my arm.

Re:A language that compiles to JS

[Jason O'Neil]

I'll vouch for haxe. I use it on any web-dev projects where I get the chance, both Client and Server side.

Basically it's a language that compiles to other languages - JS, ActionScript and PHP being among them. When using it for targeting javascript, you get some advantages:

  * Strong typing, like you're used to
  * Compile time error checking
  * Code-completion (based on the compiler, really helpful for avoiding Typos)
  * Some powerful libraries - tweening, remoting (passing objects and function calls to the server etc)

The big disadvantage is it's harder to make it work with native libraries. Not impossible, but harder. JQuery support comes built in, and there are "externs" for several of the popular libraries, and you can make your own, but it is usually more work initially. I still think it's worth it for the things mentioned above.

Other sites that might explain it better: http://www.haxejs.org/ http://haxenode.org/

Re:A language that compiles to JS

[DrXym]

GWT works extremely well. You can write most of the code in Java but there are some hooks to invoke JS if you have to. Biggest issue with GWT is it is a subset of Java and things in Java that you might expect to be there by default simply isn't. For example Class.forName() isn't there, dependency injection / introspection isn't there, threading (understandably perhaps) isn't there, references aren't there, whole chunks of collections aren't there. It means if you have legacy code then chances are it needs work to get it to run client side but usually it can be worked around.

I spent a few days porting an Android app to GWT and was pleasantly surprised by how much I could reuse. Some of my code had to be refactored to make it pluggable (e.g. I had logging statements peppered all over the place which I had to refactor and some Class.forNames) but usually it just means using a pattern of some kind like a factory and providing an Android / GWT impl. I had to write the UI from scratch though and with GWT that basically means using GWT or a binding XML to describe the elements and CSS to style them. I found GWT's canvas support to be pretty good these days too so I was able to do some pretty painting widgets.

Javascript: The good parts

[mhh91]

I suggest reading this book, it's gotten a lot of good reviews, I've seen a lot of people recommend it to people starting out with JS.

It explains a subset of Javascript that's simple to use, and also the most used in practice.

Re:Javascript: The good parts

[markkezner]

It's also a really thin book. Burn.

Re:Javascript: The good parts

[Anonymous Coward]

Take Douglas Crockford's advice: "JavaScript is Lisp in C's clothing."

Re:Javascript: The good parts

[Leafheart]

I will second this recommendation. There are also a couple of youtube seminaries with the author which are worth reading. For example https://www.youtube.com/watch?v=hQVTIJBZook

As a Javascript developer...

[RyuuzakiTetsuya]

My advice?

Scotch.

Lots and lots and lots of scotch.

Preferably something that burns horribly on the way down and leaves you with a miserable hang over. Only because you've got to look forward to something that hurts less than JS development at the end of the day.

Re:As a Javascript developer...

[RyuuzakiTetsuya]

A serious answer is to not feel bad about using a framework like jQuery. It helps to know what jQuery's doing on the inside first and foremost.

Re:As a Javascript developer...

[RockGrumbler]

ActionScript 3 supports static typing, objects, and function pointers. It's honestly a nice language compared to JavaScript.

Re:As a Javascript developer...

[gl4ss]

*On the other hand, given shared_ptr and now lambdas, who'd want to write in Java over C++, anyway? ~*

someone who hates first editing the header to add a method and then the source file.

Not an Old-School Problem

[RonBurk]

Most "old school" programmers have some interpreted language in their toolkit. People who think "old" means 40 probably have Python/Perl/etc. People who are really old probably had Basic/Awk/etc. So, nothing to do with how long you've been programming, more to do with how narrow your background is. As with learning any new language, there's no getting around the basic advice of: Write More Code.

Dart?

[supersat]

Have you tried Dart? It's like JavaScript but with optional typing, and it compiles down to JavaScript.

Re:Dart?

[Timmmm]

I've looked at Dart. It seems like javascript but with all the "hey, that's actually fairly neat" features removed, and their stupid counterfeight-typing system added on. Yeah... counterfeight typing. You heard it here first. Looks and sounds like static typing, but it isn't.

They probably *wanted* it to be static typing but supporting compile-to-javascript meant it was easier for them just to say "sod it, let's make it dynamically typed and call them 'annotations'". That's the only sane explanation for the insanity I can come up with anyway.

I still don't see why they couldn't have come up with a proper mostly-language-agnostic bytecode for the web. Like what LLVM sounds like it should be (but isn't).

Re:Dart?

[supersat]

There is a version of Native Client called PNaCl which runs LLVM bytecode, but it's not finished yet...

Re:Dart?

[Threni]

Counterfeight? I certainly did hear it here first. Sounds a little like what the rest of us call counterfeit. You're using a strongly typoed language, right.

Re:Dart?

[Concerned Onlooker]

"Have you tried Dart? It's like JavaScript but with optional typing, and it compiles down to JavaScript."

If the typing is optional how do you actually program it? Voice recognition?

Re:Dart?

[Timmmm]

Yeah I know, but apparently LLVM "bytecode" is really compiler IR, and not really suitable as a language and machine neutral bytecode. (It has specific x86 instructions and so on. There was a widely-linked mailing list message a while ago about LLVM not being suitable for use as a low level virtual machine.)

Re:Dart?

[Lord of the Fries]

Interesting term. I can clear up the guesswork on why the type system is the way it is a little bit. Lars Back and Gilad Bracha, two of the primaries for Dart, came out of the Self group. Self was an interesting Sun funded experiment where they took the "pure objects all the time, all the way down" ideas behind Smalltalk and took them to a new level by throwing out the classes as well. One of the things pursued was a dynamic method dispatching system, that while dynamically typed (this is different than untyped), could get as much mileage as possible out of run time navel gazing to dynamically optimize the execution. There are some good papers describing how cool some of the stuff they did was/is. This group already liked the idea/value of dynamic languages, and have since been involved in various projects all built around this idea: take a dynamic typed system and make it go fast. Strongtalk was what followed. And then Sun bought them back and their work became the HotSpot VM. And Lars built an embedded Smalltalk along the same ideas in the meantime. While doing prison time with Java, Gilad began Newspeak (a module happy variant of Self/Smalltalk/etc). And Lars helped with the V8 JS engine that everyone knows well about. Along with all of this, all the way back to Strongtalk, they've always held that while a runtime system should be entirely dynamic (e.g. no hints required from a static type system), they see great value in being able to express types from a documentation/communication pov within the code. So the type systems, that any of these languages have had (which all share these similar values) have always been for expressiveness only. Personally I don't agree with this, but it's an interesting position that I've always tried to appreciate.

Adapt or die

[Telek]

This depends - are you looking to learn the new coding methods to remain competitive in the workplace, or just for fun?

Honestly if you make a living doing this then you need to adapt. You need to get over your preconceptions and accept the changes to the way computing works. There are millions of programmers out there, if you want to stay employed you need to show that you're adaptable to the new technologies while applying all of the tried-and-true knowledge and experience from your past. It's hard enough to get a job when you're more than a decade out of school.

Trust me, I understand where you're coming from. I hate the inefficiencies of the languages these days. I dislike the general idea of doing anything other than a script in a scripted language. However my (perhaps anachronistic) viewpoints don't have many applicable places anymore. Unfortunately the tradeoff between RAD and proper coding often leans a little too far to the RAD side, necessitating the use of many types of languages and tools that you will undoubtedly not enjoy.

Not only will you be a lot more productive, but you'll be a lot more marketable if you just succumb to the "dark side" that is today's trend in programming languages.

Re:Adapt or die

[Threni]

That's why he asked the question.. Do you have an answer?

go assert yourself...

[TheCouchPotatoFamine]

let go, my man... breath the untyped air.

Real tip: "use strict" at the top of your code and and write using assert() methods. A little more tedious, but your used to that, right? Being "dyed-in-the-wool" and all...

one word: JQuery

[thatisscary]

While it won't get you over the loosely typed nature of the language, it will make things a bit more manageable. You can write nice terse code which accomplishes oodles, as opposed to hand rolling everything. There is something nice to javascripting. I find it a nice respite. JQuery makes it beautiful.

Re:one word: JQuery

[coffeeyesplease]

Completely agree. My advice to you is learn JavaScript on it's own merits. Stop comparing it to C/C++/Java or whatever. heck, you might even have to stop thinking in objects and all that comes with OOP because sometimes it just doesn't apply. In my experience and for what I see with most of my programmers, is that no one really bothers to learn JavaScript. They just keep on doing whatever they're we're doing in C/C++/Java and then complain about how crappy everything is. A good starting point is this book http://eloquentjavascript.net/ it's free and it's a also refresher on computer science in general, download chrome or firefox (with firebug) to help you debug (c'os that's a frustrating task, at times) As someone mentioned already it's a completely different mindset. I personally have a hard time programming anything that is not strongly typed. Mainly because I'll go into it already thinking that I don't like it.But for someone who's been programming applications (some web, some not) for 13 years, JavaScript can help you achieve wonders. I find practically unavoidable when it comes to web applications and it has helped me achieve some UI stuff that I thought impossible just last year. (and yes, JQuery is a must)

That's an antipattern

[slimjim8094]

I have no particular love of Javascript, but when I work in it, I write Javascript. When I use Python, I write Python, not Java. When I use C++, I write C++, not C.

It's hard. It's annoying. But the idea is that you write the language like a "native". If you're really a generalist, it's not such a big deal. Read plenty of good Javascript to learn the idioms common to the language, and go from there.

I could write for loops using counters and statements terminating with semicolons in Python. But I don't. I use iterators, list comprehensions, and so on. Because that's how Python code is written.

The way I see it, the goal of learning a new language is the same whether it's a programming language or a spoken language - to be able to do useful things with it, and ideally come off as a native speaker. Look at it as a matter of pride.

Re:That's an antipattern

[multipartmixed]

If you've been programming long enough, you realize that programs have "shapes" and programming languages are really .. like, ah..spoken languages.

Most people think of callback-heavy library routines, reams upon nested reams of functions (encouraged by jQuery and ilk) when they think of the JS language. This language makes it particularly easy to write programs of certain shapes (spaghetti is a shape, right?). Just like it is probably easier to write an opera in Italian (or Klingon) than Russian, because the words flow into the form better.

But, when writing JS to do UNIXy things, the code starts to feel a lot C, because the shape is UNIXy and we strongly associate C with UNIX. Just like a Russian rock song still sounds like a rock song. It might sound a little wonky, but you would totally identify it as a rock song because of the form (shape).

Here's a snippet from some UNIXy JS I wrote a couple of years ago. Obviously, it's not for the browser, it's for a POSIX system -- and I think that makes my point:

/**
  * Determine whether two paths refer to the same storage (file or directory), either by
  * virtue of symbolic or hard links, such that modifying one would modify the other. In
  * the case where either some or all paths do not exist, we return false. If we are
  * unable to verify if the storage is the same (such as by having insufficient permissions),
  * an exception is thrown.
  *
  * @param pathA A file or directory name
  * @param pathB A file or directory name
  * @returns boolean
  */
 
exports.same = function same(pathA, pathB)
{
  var sb1 = new ffi.MutableStruct("struct stat");
  var sb2 = new ffi.MutableStruct("struct stat");
 
  if (stat(path, sb1) != 0)
    sb1 = false;
  else
  {
    if (stat(path, sb1) != 0)
      sb2 = false;
  }
 
  if (!sb1 || !sb2)
  {
    if (ffi.errno == ffi.dh.ENOENT)
      return false;
 
    throw new Error("Unable to compare '" + pathA + "' and '" + pathB + "'" + syserr());
  }
 
  if (typeof sb1.st_dev != "undefined")
    if (sb1.st_dev != sb2.st_dev)
      return false;
 
  if (typeof sb1.st_rdev != "undefined")
    if (sb1.st_rdev != sb2.st_rdev)
      return false;
 
  return sb1.st_ino == sb2.st_ino;
}

Re:That's an antipattern

[narcc]

"Wow, this actually reads a lot like Java, it's very clean".

That doesn't make any sense. If it reads like Java, how could it possibly be considered clean?

Re:That's an antipattern

[Terrasque]

Hah, +5 Funny truth

Whenever I look at java code it's all that gooblygook structure with a morsel of actual logic hidden deep inside it.

It's like those restaurant meals where your order comes on a large plate, the sauce is in sophisticated patterns, plenty of green and red and other colors, and so on. But the actual real food itself is barely a mouthful. The rest is just chaff to make it look good (or in Java, to make it look yummy to the preprocessor).

Know the language, practice safe coding

[plopez]

Know the language well, sometimes you *want* wierd things to happen. But know the limitations. Also practice safe and defensive coding. Use facilities you have to minimize side effects. Test early and test often. BTW, both C and C++ can really bite you. So I find it odd this question is being asked. These habits should already have been developed. I've been there so I know.

Re:Know the language, practice safe coding

[nomel]

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

Why?

[LizardKing]

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.

Re:Why?

[hibiki_r]

Dynamically typed languages almost demand a large unit test suite to minimize quality issues. TDD and all that. If you are going to do that anyway, the dynamic language's weaknesses don't come into play as much, and you get the advantages, like typically needing a whole lot less code to get the same thing done. Look at Groovy, for instance: You can typically reproduce a Java program in half the code, and that if you are not facing one of those problems where dynamic typing really makes your life dramatically easier.

should get you started...

[VoidEngineer]

First, get thee Aptana for development.

Second, download thee jQuery. I would also recommend jQuery Mobile and jQuery.tools.

Third, dig around in jquery until you find qunit for unit testing.

Fourth, do a refresher on Lisp and functional languages. They say that javascript got it's fathers curly braces and it's mothers lexical scope. It may *look* like C/C++/Java, but under the hood is ActionScript ala Scheme ala Lisp. And it a very real difference which gets played out in copious usage of events and callback functions. As a refresher, the HTML5 paradigm is basically an MVC paradigm, where HTML is handling the Model, CSS is handling the View, and Javascript is handling all the controller functions. Phrased differently, the HTML is describing the What is displayed; CSS is describing How it should be displayed, and Javascript is describing When it should be displayed. And the When gets implemented as callbacks and events. And it just so happens that functional languages are ideally suited for that kind of work (ala lambda calculus, etc).

Lastly, if you're brave, check out Node.js.

Seriously, find something else to do...

[Assmasher]

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.

GWT

[alannon]

I think GWT is actually a reasonable tool for writing code that compiles to Javascript. This makes a lot of sense if you're writing your server code in Java, since your server and client code can all live within the same source tree and be edited with the same IDE in the same language. Significantly, this also allows you to debug your code using your Java debugger (read up on 'hosted mode' if you want to understand that witchcraft) while it's running in your browser. GWT also de-fangs the javascript event model that often leads to memory leaks. It might be of benefit to some people that by default (you can turn it off) the emitted JS code is heavily obfuscated. GWT is mature and well-supported, and integrates simply with vanilla JS code if you wish to.
Available for GWT is GWTQuery, which is (you've probably guessed) a jQuery clone for GWT, including events, effects, etc...

Try the Dojo Toolkit

[hilather]

The Dojo Toolkit definitely makes javascript feel a little more friendly.

My tip

[bonch]

My tip is to never let yourself remain attached to a particular subset of languages for 20 years. Absorb all crazy things, because it makes you better in all languages.

Try LISP sometime.

Dynamic typing is paradise. As is static typing.

[Qbertino]

I'm just going the other way. Building my first app in C++ using Qt. Which basically goes like this: OMG you piped a literal string without it being a genuine QString into my label ... KERNEL PANIC! CRASH! 10 bazillion compiler errors. ... WTF?
Of course this sucks. However I'm well seasoned enough to know that when building a non-trivial application, it's exactly this sort of thing that will save my sanity in the long run.

With dynamically typed languages it's the exact opposite. Try building an IDE in JS. It has been done, but it need a solid amount of thorough planning and the one or other hack/stunt. However, writing a little script in JS is like having awesome sex compared to doing the same 'three-liner' in C++ which is like masturbating with a cheese grater in comparison. And still uses 30 lines.

All I can say is go with the flow. Wrap your head around dyn typing if you are not used to thinking in it and eventually you'll see the beauty in JS which blows C++ out of the water in the areas it is meant for.

Keep up with the spirit and good luck. ... And now excuse me, I have to set up my little QWidget 20-something lines of code with 20 typecasts strewn about just to get the bloody label to show a simple literal when I click a menu entry.

My 2 cents.

Use Google's 'Closure Compiler'

[arthur5005]

http://code.google.com/closure/compiler/ It's exactly what you're looking for. It does type checking, it checks syntax and variable reference, it does file dependancy, and has a great inheritance system so you can get back to your Java/C++ ways. It's just awesome.

Be dynamic when you use a dynamic language

[steveha]

Dynamic languages have different strengths and weaknesses than static languages. The best advice I can give you is: deal with it.

Best practice in a dynamic language includes automated unit tests for your code, for example. I don't use JavaScript so I can't tell you all the best practices and developer idioms for JavaScript, but I have heard that the best book is the O'Reilly reference book and that anything by Crockford is worth reading.

Note that lots of other Slashdotters are already giving you very similar advice to what I wrote.

P.S. Hmm, doing a Google search for "JavaScript best practices" found this: http://www.javascripttoolbox.com/bestpractices/

steveha

Get Over Yourself

[cthlptlk]

Nan-in, a Japanese master during the Meiji era (1868-1912), received a university professor who came to inquire about Zen.

Nan-in served tea. He poured his visitor's cup full, and then kept on pouring.

The professor watched the overflow until he no longer could restrain himself. "It is overfull. No more will go in!"

"Like this cup," Nan-in said, "you are full of your own opinions and speculations. How can I show you Zen unless you first empty your cup?"

Have Fun With It

[Bob9113]

You're right, Javascript is a way different style of coding than C/C++/Java, but that's OK. So is Lisp. Surely you wouldn't feel wounded by having to learn Lisp. Use the different style to develop a new facet to your perspective on programming. Duck typing is pretty well respected in academic OOP, so it's not like you're going to be learning GOTO statements or anything.

Debugging is a bit harder, but that's OK, fire up Firefox, go to "Tools >> Web Developer >> Web Console." That'll give you most of what you're looking for (use console.log("message") to write to the console). You can check out Firebug also, if you want something a bit heavier. I personally ditched Firebug as soon as Firefox's Web Console got good enough, because I found Firebug a bit too clunky, but lots of people swear by it.

Leave the preconceptions and stereotypes behind, check out Wikipedia on Duck Typing and give it a go. Don't sweat it when you make noob mistakes -- you're supposed to do that when you're a noob to a language. Give it a crack, have fun with it, relax, it's really not a bad language once you get into it.

Perl

[rrohbeck]

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

It's a good time to look, but I wouldn't jump in

[fean]

Take a look at Sencha / ExtJS... It's aimed squarely at enterprise-level developers/engineers, not the script-kiddies that rant and rave about the cool shit they can do because they've overwritten a 'built-in' type. It should work with Google Closure, as well...

IDEs are in terrible shape. There's WebStorm and Aptana... neither of which hold a candle to what you're used to, but it's better than notepad/textmate. I'm an linux/eclipse guy, but can't get used to the ways that Aptana breaks shit, so I tend to jump back and forth between WebStorm and SublimeText (it looks nice, but it's not 'all there').

There are some good books out there, JS: The Good Parts, Eloquent Javascript (free)... and I'm starting on Test-Driven Javascript Development, though I can't say if it's any good yet...

I'd recommend doing a little bit on the side, get your feet wet, but don't commit yet. Thinks have changed a lot in the last year or two, and nearly everyone and their dog is becoming an HTML5/JS Dev. You're behind the curve already, and will have a hard time getting ahead, so I'd wait until the editors and browser compatibility is better before diving in.... don't ignore it, and if you can find someone who will pay you to torture yourself, do it... but don't be too anxious.

Dynamic languages have static rules

[btherl]

Dynamic languages actually have strict, static rules behind them which implement their dynamic features. If you learn those rules then you may be in more familiar territory. Weak typing is really just a list of rules for automatic type conversion.

Re:GWT

[JThaddeus]

I second this. I've been using the Google Web Toolkit (GWT, http://code.google.com/webtoolkit/) for about 5 years now with good results. Write in Java, compile to Javascript, and let GWT handle the browser differences. The source is all there if you want to see how their Javascript works, and you can insert you're own Javascript code when and where you want it. Finally, the user's group has been an excellent source of advice.

These steps broke the logjam for me

[Beeftopia]

I'm a C++ guy and here's how I got conversant with Javascript:

1) Get "Javascript: The Definitive Guide", by Flanagan, published by O'Reilly.

2) Read the chapters on Objects, Functions, Classes and Constructors.

3) Wrap your head around closures.

4) Understand the concept of function prototypes.

It's different than strongly typed languages. Just about everything is an "object" in Javascript. Including functions. Learn the subtle difference between defining and declaring a function - and it's nothing like what that means in C++.

Take from C++ the concept that you can have objects which have methods and properties. Then open your mind and read those chapters I mentioned. And don't try to apply any more C++/strongly-typed preconceptions. The "Definitive Guide" was not pleasure reading. It's not informal and humorous. It's dense. And it's geared towards those with some programming experience. But read those chapters and I think you'll be most effectively able to leverage your experience with strongly typed languages into Javascript.

I think Javascript is great and it is object oriented so you can get jiggy with it.

Also - give yourself an assignment with it and start hacking away.

Go with the flow, my man

[multipartmixed]

I have 20 years of C under my belt, 15 of those paid. I currently spend the vast majority of my time writing JS, and I love it.

Back in the good old days, we didn't pick C because of it's great syntax, or the warnings from the compilers (which have gotten much better in the last 20 years!). We picked it because it fast, portable (enough), available, and you could use it to do the stuff we were interested in.

Well, times have changed. JS and CPUs are now fast enough that execution time is not were "fast" usually matters: *developer* time is. JS syntax is good enough. Runtime warnings are getting good enough if you're writing ES5 strict code. Most importantly, if you're writing code for the web, you pretty much have to pick JavaScript. (Just like writing X11 code 15 years ago pretty much meant C++).

Syntax -- "go with the flow, my man". It's juicy, delicious. Don't be limited by the lack of types: embrace the flexibility. Prototypal inheritance is awesome in its simplicity, shallow object hierarchies make for easy reasoning. Make you *get* closures.

Functions are first-class members, like strings and arrays and objects. Sure, their literal syntax is longer than "", [] or {}, but function(){} is still a literal.

Just as the developer who thinks GNU make is some kind of super-shell is doomed to failure, so will the developer who thinks JS is a variation of something else.

JS isn't the new C. It's not the new Java. Or C++. Or Scheme. Or Perl. Or Python. Or Logo. Or BASIC. It's JS.

I currently write a LOT of day-to-day mundane code in JS. Some exciting code, too. I write web pages, validate forms, load modules (CommonJS), and design object exchange protocols and the applications which use them. That's on the web browser.

On the web server, I'm using it kinda like 1995's PERL. I query databases, do CGIs. I can call into POSIX. I write daemons, and "shell scripts". Some week I'll spend a few days and make my CGIs faster than CGIs. Remember mod_perl? Same deal. Mast fast_cgi. I dunno, performance metrics say I don't need to quite yet.

It's a hell of a language. But if you really want to work with it, you have to "get it". Be comfortable with it's multi-faceted layer. Understand that it's "functional", "object oriented", and "imperative", all at the same time.

In C, the Zen boils down to "everything is just a number". That's why string operations are so easy in C once you "get it". In C, the Zen boils down "everything is just a jsval". So, it's IS typed -- everything is the same variadic type. Get over writing reams of code to make your little soldiers walk the goose step, and just tell them where to go. They'll get there.

Re:JS is not OO

[BitterOak]

Javascript is not perfect but more importantly, it's not OOP.

Actually, Javascript is object oriented. It's just that, unlike most object oriented languages, it is prototype based rather than class based. Both are legitimate forms of object oriented programming, although class-based is more popular now.

Javascript: The Good Parts (Douglas Crockford)

[oldspicepuresport]

This is book is worth every penny and more (~$18 on amazon).

Like the submitter, I come from C/C++/Java background and always despised Javascript whenever I had to deal with it. I picked up this book a few months ago and can confidently say that this book completely changed my view of Javascript. Javascript is a quirky language, and has some really bad parts (the book has a chapter dedicated to the bad parts). This book clearly explains common misconceptions about the language, as well as all the things a programmer used to a more traditional language needs to look out for. The book explains how Javascript works under the hood in great detail (the prototype-chain, functional scope, type conversion and equality, first class objects/functions ,closures, etc.)

This is a book for programmers, it's not a cookbook or how-to, and you need a good understanding of programming for it to be useful. That being said, for programmers coming from more traditional languages to Javascript, this book is exactly what you're looking for. I can honestly say that in a few short months Javascript has gone from one of my most hated languages to one of my favourites. The language is incredibly powerful and expressive once you get a good understanding of how it works and why.

Here's an example

[gr8_phk]

How does the code look that much different? Besides some syntax differences, they're all almost *exactly* the same. Some languages force you to format your declarations and types differently, but a for loop is a for loop

for (x=0; x lessthan 10; x++) //sorry, can do lt in comment
{
square[x] = x*x;
}

That's a for loop, while this:

square = [x*x for x in range(10)]

is a list comprehension in Python.

You can write it like a for loop - and I did when I was first learning Python - but it sucks to do that. This is probably what the GP was alluding to. If you really know a language you don't want to read crap written by people who think they're all the same with different syntax. This of course is but a single small example.

Use Coding Standards, Libraries, and Good Books

[strimpster]

A language is not evil because it isn't strongly typed. Just because a language offers that option doesn't mean that you have to use it though. There are a lot of things that languages offer that aren't the best tool in all cases. This is where coding standards come in really helpful :)

That being said, I think that these could help you out:

• JSLint - this is a linter that has some IDE support to help ensure that your code will adhere to some good standards
• jQuery - this will help to abstract browser differences away so that you don't have to worry about that to cause your site to not work
• QUnit - this is a test suite to aid in development
• JSCoverage - helps to measure code coverage of unit tests.

JavaScript has been around for a long time and has lots of books and articles written. This is a huge benefit. I personally think that JavaScript Patterns by Stoyan Stefanov is a good quick read to show you how to implement popular design patterns in JavaScript. A deeper discussion can be found in his book Object-Oriented JavaScript.

Re:I thank you for y0ur time

[Spiked_Three]

Yes, that is what Java script code looks like.

Sure ... The first thing you should do is

[hey!]

Stop building narratives like "I'm an X type of guy trying to do Y." That's bound to increase your frustration with what are most likely going to be the normal road bumps in learning to do things differently. Think "different tools and methods for different jobs."

Instead of asking "how do I make working in toy language like Javascript tolerable for *real* programmer like me," you should be asking "how do the very best Javascript programmers do what they do?"

And don't think of yourself as "dyed in the wool" anything. Think of yourself as a versatile person who likes learning about new ways of doing things, because you've got a *lot* more to learn than just the Javascript *language* if you want to actually *use* Javascript. You've got to learn about DOM and CSS and HTTP and web application architecture and security. Once you learn about those things and learn how to actually do something useful with Javascript, you'll be in a much better position to make an *informed* critique the design of the language, popular libraries and frameworks like JQuery, and common Javascript idioms. It makes no sense to approach mastering the whole Javascript ecosystem with preconceived notions about its shortcomings. You aren't qualified to judge yet.

Learning a new kind of tool means learning new kinds of skills and strategies. Some aspects of the tool will seem like major problems with the tool until those good habits become second nature. For example novice Java programmers tend to create code that allocates unnecessary strings inside loops, when they should be using a StringBuilder. The result is the programmer thinks that it's Java that's slow, when it's really their ignorance of efficient Java programming idioms that's to blame.

You have a clear anti-JS bias.

[Static]

Your post reads a lot like all those people who hate PHP. "It has all these things wrong with it!" Well, actually, no it doesn't - because most of them aren't a problem to the people busy using it effectively. JavaScript doesn't have 'inferior' abstractions: it has *different* ones.

I have programmed a lot over the decades in both strongly typed and weakly typed languages - too many to name. I've come to Java in the last few years after a much longer time in JavaScript and PHP (and others) and have experienced the reverse of the OP's problem. But it's only a problem if you let it be a problem. Solving problems in an untyped language has some fundamental differences to a typed language. Get over that and a lot of the perceived 'problems' Just Go Away.

Re:You have a clear anti-JS bias.

[Anonymous Coward]

Your post reads a lot like all those people who hate PHP.

So he's an experienced professional software developer who cares about the reliability, performance, maintainability, correctness, portability, and the overall quality of the code he writes. That's not a bad thing at all. You should listen to him. What he wrote is absolutely right.

Re:You have a clear anti-JS bias.

[Alex Belits]

How about never ever passing any input to SQL interpreter, use prepared statements based on nothing but constants, and always store data in bind variables? Even MySQL supports that.

Of course, it's not PHP's fault that mysql_real_escape_string() is a part of MySQL API, however it would be nice if a language widely used for database-backed web applications did not support the most idiotic way of passing data to the INSERT statement.

Re:Dynamic typing is paradise. As is static typing

[Anonymous Coward]

... And now excuse me, I have to set up my little QWidget 20-something lines of code with 20 typecasts strewn about just to get the bloody label to show a simple literal when I click a menu entry.

You're doing it wrong
http://stackoverflow.com/questions/1814189/how-to-change-string-into-qstring

Your are clearly too rational to be here...

[snowgirl]

Please get off the intarwebs... your clear and concise explanations of matters is undesired here in this wretched hives of memes and flamewars.

Seriously though, you're totally right. It's different. It's not inferior, it's different.

People who complain about this or that language being a piece of crap because of X and Y, are usually deadset in one particular mode of thinking, and cannot adapt. The question the original author should have been asking was not "how can I make this tolerable", but rather, "how can I best learn the correct way to use this tool?"

To put things in perspective, I was already doing a lot of crazy command-line parsing before I ever started using C. And when I started using C, I was upset, because I knew what I wanted to do, and I could easily accomplish it in BASIC, but C was different. The whole paradigm was new to me, and I had to learn to adapt. I haven't forgotten that, and I try to keep myself from becoming entrenched in any particular mode of thinking... it leads to inflexibly dictating that all else is inferior.

Re:Your are clearly too rational to be here...

[shutdown -p now]

It makes no sense to claim that programming languages can't be meaningfully compared with respect to things like efficiency, conciseness, level of abstraction etc. It may be politically correct (towards VB/PHP/JS crowd), but it's still false.

Yes, languages differ. Yes, there's no single one that's the best. No, that doesn't mean that your favorite language is just as good as mine (unless your favorite language is Common Lisp).

Re:Your are clearly too rational to be here...

[justforgetme]

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:Your are clearly too rational to be here...

[Alex Belits]

web

Here is your problem. Javascript is an awful language, it just by the whim of Netscape it is the only one available in a browser. This does not mean, Javascript is good, it means that Netscape fucked up, and no one was around to fix the problem because everyone was busy fending off Microsoft and Adobe, who tried to "standardize" everyone on things that make Javascript look good.

A good solution would be to use Java or C++ with Qt, and distribute the application with sources (and everyone who opens his mouth about revealing the source code is welcome to shut up because Javascript is always distributed in source anyway). This may be an overkill for something as simple as a widget for displaying lists/icons/graphs..., but for a complex application Javascript is still a bad language.

Same applies to writing "for consumer PC" and Win32/.NET/other horrible things from my "favorite" company.

Re:Your are clearly too rational to be here...

[TheRaven64]

I'll prefix this by saying that Javascript is not my favourite language, although I have written a compiler for a dialect of it and an Objective-C compiler that emits JavaScript.

A lot of what you're talking about has nothing to do with the language and everything to do with the libraries. Given a DOM binding and a function for generating asynchronous HTTP requests, everything that you request is pretty trivial in most high(ish)-level languages and would almost certainly perform better. Writing a fast implementation of JavaScript is insanely hard. One of the big reasons why it is easier to make Java perform faster than Smalltalk - in spite of the fact that the two have a lot in common in terms of memory and object models - is that Java has integer types, so a + b can be compiled to a single add instruction by a naive compiler, while doing the same thing in Smalltalk requires you to perform some nontrivial type inference. In JavaScript, it's even worse because integers must transparently overflow to double-precision floating point values.

It would almost certainly be more maintainable too. JavaScript was intended for scripting, not for writing large applications. It lacks any module feature - or even classes. You can split a JavaScript program into multiple files, but then including them in a different order can significantly alter the semantics of the program. In other languages, you can separate independent parts into separate components and not, for example, pollute the global namespace with local concerns.

Re:Your are clearly too rational to be here...

[shutdown -p now]

Now how easily would you create an asynchronously interactive web site without javascript and how would it perform?

You need to define what a "website" is for this to work.

The problem is that "website" is, effectively, defined by W3C. And W3C, in their infinite wisdom, standardized on JavaScript as the scripting language for the web. So, as of today, the definition of website essentially includes JS, and excludes other languages, making any such comparisons irrelevant.

We came up with some workarounds for that, like X-to-JS compilers. Unfortunately, because the end result is still JS, this approach doesn't let you actually realize the performance benefits of a statically typed PL on VM level, since all types are erased by the time code is running.

However, it is perfectly possible to do a "what if?" - take some other PL, and see how well it would fit into the niche occupied by JS today. And if you do that, you suddenly realize that practically any mainstream dynamic language, excepting possibly PHP, would do all the same things better.

Re:Any rational programmer is anti-JS

[John Courtland]

Javascript has closures and none of the other languages have them, sorry buddy, Javascript has superior abstractions.

B0rked closures is enough for JS loving?

[Anonymous Coward]

Java has better closures. Clunky, sure, but not broken.

Scala has better closures. Closures you can love.

Haskell has total awesomeness oozing out of its handling of closures.

Javascript is retarded in all ways. It's just flabbergasting that anyone defends it.

Re:Any rational programmer is anti-JS

[shutdown -p now]

Javascript has closures and none of the other languages have them

All mainstream languages except for Java have lambdas/closures (and Java is getting them in the upcoming release).

For that matter, most languages that do have lambdas, provide syntax for them that is considerably less verbose than that of JS - which makes a lot of sense when you actually start using lambdas heavily. To give an example with fold used to sum a sequence (assuming fold is a member function in all cases, for the sake of uniformity, and ignoring the ability to treat operator itself as a binary function in languages that support it):

// JS
xs.fold(function(x, y) { return x + y; });
 
// C#
xs.fold((x, y) => x + y);
 
' VB
xs.fold(Function(x, y) x + y)
 
// Java 8
xs.fold((x, y) -> x + y);
 
// Scala
xs.fold(_ + _)
 
# Python
xs.fold(lambda x, y: x + y)
 
# Ruby
xs.fold {|x| x + y }

the trick is...

[holophrastic]

you developed a style for those other languages. and you based that style on the strengths of the language -- I hope.

the only thing that you need to do is to see what javascript does that your other languages can't feasibly do at all. And here's the example:

window.parent.self.document.body.frames['headerFrame'].contentWindow.parent.document.body.getElementById("eNavBar-26s-t").offsetParent.children[7].style.top = "35.4cm";

it's all about the most efficient way to develop using the DOM. forget about processor efficiency, it's about developer speed. forget about the ability to create complex structures, they are already there. the DOM is as complicated as the above, and moreso. There is already an API to an application (the browser itself) and you've got huge structures tto play with, and they matter in real time.

the above snippet navigates from virtually no where through window placement and size through child and parent windows and embedded browsers, both into and out of embedded browsers, to a specific element then to related elements then to an unrelated element, then moves it to a location that may or may not be relative to other locations.

so in that above case, you're going through the presentation layer (the web page html), the network layer (tcp/ip), the window layer (the tab and chrome and buttons), and the content layer (your actual content between html tags). and you can set anything along any one of them, and it just changes, magically.

it's data-centric programming. you aren't calling functions and issuing commands. you're just changing data structures, that's it. something else (the browser), is monitoring those changes and acting of its own free will.

cool or not, it's wildly different than instructing a computer to do things. you're not. you're just manipulating one huge data structure -- and it's nested, and hyper linked, and looped.

c and java aren't very good at playing with unbalanced crazy data structures. perl is (see auto-vivification), and javascript is.

now, the fun stuff that you'll get to in javascript is the world of polymorphism. if you wanted to use javascript for non-web stuff, you'd go ape shit over the ways in which javascript can do really cool things with prototyping and inheritance. and the fact that it all becomes visual too is really fancy compared to the java or c equivalents. but most web programming doesn't use that sort of thing, so you won't be quite that happy most of the time.

think about linked lists without have to handle them yourself, then think about hyperlinking in data structures the way the web hyperlinks urls. it's not about programming the way you're used to. it's not the same. they call it programming, it's not. it's not even scripting, because you're doing nothing more than changing an existing data structure. everything's a utility function that you write to change the existing data structure.

it's not programming, and it's not scripting. it's scripted mark-up, which is exactly what it is. it's taking html markup, and describing the way it should change dynamically. it's dumb-fk stupid, and it's really basic simple, quite frankly, LOGO was more effortful to code, but because you have so much output and control over levels of interaction with living users, it's fun.

but it's not interesting at the programming level. it's not about that.

so how should you do it? have a browser window open at all times. change one line, hit refresh, see the change. it's not about the code. the code isn't cool. the output is cool. look at the output, not at the code. you should refresh about 100 times per hour of coding. you should make yourself small output consoles to watch variables and track output as you need it. you should be staring at the output, not at the code.

Two Book Recommendations And A Philosophy

[nick_davison]

The key, as others have said already, is to stop fighting it.

JavaScript, as it was seen five years ago, was just an ugly language with horrible conventions. Then some very smart people looked at how to embrace those conventions and start doing utterly cool things that you can't do in other languages.

Learn from what they've done. Look at the cool tricks you can perform when everything is a hashmap, is an array, is an object. Look at how stupidly easy it becomes to do concepts that are endlessly painful in other languages. Have fun with it.

If you can see JavaScript for what it's become, you can have a huge amount of fun. The same part of your brain that has fun with optical illusions, M.C. Escher and even Jon Carmack's ability to break all the rules set before him to create amazing code that does amazing things, the nerd part that liked the idea of Neo bending reality? Don't fight it, revel in it. JavaScript, as it's become over the last few years, is an amazing playground.

So where do you learn to have fun poking all of those holes in reality? I learned a lot by looking at the uncompressed jQuery code and figuring out how they did things smarter than I knew how. I've also found two great O'Reilly books... Douglas Crockford's (learn that name) JavaScript, The Good Parts and Stoyan Stefanov's JavaScript Patterns.

JavaScript, The Good Parts will give you a really solid understanding of what JavaScript really is, how it can be used for evil (the old assumption) but also a lot about how it can be used for good (what we've all been discovering over the last few years).

JavaScript Patterns is fascinating because Stefanov certainly covers the standard patterns you should already be used to (Factories, Builders, etc.) but then, and this is key, recognizes that JavaScript functions in sufficiently unique ways it's worthy of having its own patterns considered.

Both of those books, plus the jQuery code, will give you a real sense of how it's possible to play in JavaScript's playground. When you're aching for structure again and miss having a compiler tell you you're an idiot and you've done everything wrong... Run it through jslint. JSLint is brutal. It's not there to be your friend. But use it constantly and it'll turn you in to a way better JavaScript coder. Now you get to code fantastic rule breaking whilst still keeping it clean and intelligently structured anyway.

It's not C/C++. But, let yourself think in the new ways JavaScript offers and it's incredibly refreshing.

Re:Any rational programmer is anti-JS

[velinion]

Wow. Lisp has closures, and it dates back to 1958. Not that I like Lisp a whole lot. I prefer to have syntax beyond parenthesis.

When I need closures and a functional programming paradigm, I usually turn to OCaml myself. (Cue hated from the lisp crowd)

Seriously, programming language preference is like editor preference. It has a lot to do with what you are most used to, and a lot to do with how your mind happens to be most comfortable thinking.

I prefer the much shorted debugging period afforded by strongly typed statically typed languages, even though it forces me to jump through some hoops that a weakly typed dynamically typed language would save me form. Personally, I've coded in C, Java, C++, Perl, Python, OCaml, Lisp, Scheme, PHP, Prolog, Javascript (very little) and Basic. Among these, Perl, Ocaml, Lisp, and Scheme all make extensive use of closures. Others may as well. (I just haven't used closures in more than those 4)

Re:Any rational programmer is anti-JS

[Anonymous Coward]

I guess C++ isn't a mainstream language anymore. Go figure.

Actually, C++ has it since C++11... but with typed arguments of course:

# C++
xs.fold( [](int x, int y) { return x + y; } );

Of course, both Javascript and C++ are still much less powerful than any variant of LISP.

Smart Mobile Studio

[Barryke]

AFAIK, this is a Object Pascal ~(Delphi, Free Pascal) to Javascript "compiler".
http://op4js.optimalesystemer.no/about/

Example of creating a custom GUI control:
http://op4js.optimalesystemer.no/2011/10/05/your-first-op4js-custom-control/

Re:Any rational programmer is anti-JS

[homb]

And of course Objective-C 2.0:
# Obj-C [xs fold:^(int x, int y) { return x + y; });

Re:Any rational programmer is anti-JS

[rmstar]

Actually, C++ has it since C++11... but with typed arguments of course:

C++ closures are what happens to a beautiful abstraction after it goes through mordor. It becomes an orkish, vile thing more fit to hurt the user and confuse him than to achieve something of good and beauty.

I mean, where's your GC?

He wants Google Web Toolkit

[Requiem18th]

I agree, it was flammish to say JS has inferior abstractions. It DOES have LESS abstractions. But the few it has are actually more powerful and general than Java's. In other words JS is more orthogonal than Java, you do more with less, which is a good thing, and I say this as a harsh critic of JS!

But typechecking is one of those things that, while dynamic programmers like me shrug, does make a lot more sense than I usually accept. If static type checking is for you, JS isn't. However it is possible to compile Java to JS, there are several implementations but the best one is Google's Google Web Toolkit which is exactly that. A Java environment that compiles to Javascript.

Re:He wants Google Web Toolkit

[Broolucks]

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.

Re:Any rational programmer is anti-JS

[Imbrondir]

JS solution may be the most verbose, but I'd argue that it's the easiest to read, learn and understand, since it doesn't introduce more language grammar.

Re:Any rational programmer is anti-JS

[jcupitt65]

I know you said to ignore the operator-as-function thing, but it looks so nice in Ruby:

[1, 2, 3].reduce(:+)

Not that Ruby is very functional, sadly.

Typing

[Skapare]

It's the values that are typed, not the variables. That's common for dynamic languages. Some people are quite accustomed to this. You can be, too, if you want.

Re:Any rational programmer is anti-JS

[Tsingi]

It's not a bias. Javascript has inferior abstractions. Fact.

I may lower my standards and use it when forced, but I am painfully aware that I am stooping low to do so.

The OP will have his arse reamed by JS over and over because a real language does not do the things JS does. And that's just the published spec. What any actual browser does is pretty much completely random. Trying to use JS for anything real is a hopeless task.

I find JavaScript to be very powerful when used intelligently. I've used about every language out there and I've been programming for over 30 years.

You probably just suck.

Re:Any rational programmer is anti-JS

[TheRaven64]

The lack of GC - or even some approximation - is what makes C++11 lambdas completely horrible. The language does nothing to ensure that your bound variables actually persist for the lifetime of the closure. You are required to use smart pointers for all of them. This is trivial stuff for the compiler to do (in Objective-C, for example, block variables - including C values and structures - are automatically moved to the heap when required by a block persisting) and a pain for the programmer to do. So, of course, C++ makes the programmer do it...

think gwt

[mrops]

google provides gwt, you write your code in java, it compiles to javascript for all browsers. worth a look if u want web programming with java. it does have its quirky moments.

further gwt coupled with something like sencha gxt lets you write web applications not possible easily with the likes of jquery etc.

Re:Any rational programmer is anti-JS

[shutdown -p now]

Are you seriously suggesting that introducing a single new piece of punctuation, like an arrow, makes PL significantly harder to learn and understand?

If so, then I think we should throw a+=1 and a++ out of JS, as well, on the grounds that a=a+1 is the easiest to read, learn and understand...

Seriously, though, syntax is by far the simplest part of learning a new language. It's the concepts that are toughest. Once you actually understand what lambdas do - and you need to understand it for JS just as well as for any other language - it doesn't matter much how they're written down.

Re:Any rational programmer is anti-JS

[shutdown -p now]

However first time I read the JS syntax in some jquery code I immediately understood that I was passing an anonymous function with access to local scope. Didn't even have to learn or know about any "lambda concept".

That is because you understand what an "anonymous function" is, and how it works with respect to variables that are declared outside its scope - that's precisely what I meant by "lambda concept". For someone coming from, say, C, which doesn't even have nested functions, it's much harder to comprehend.

Also in python, a++ is in fact not allowed precisely because a+=1 or a=a+1 is easier to read, learn and understand :)

Perhaps, but how far are you willing to push it? The next logical step is to drop a+=1 for a=a+1. Then maybe to drop + altogether since we already have functions, so it becomes a=add(a, 1); etc. Another example is "for", "foreach" and equivalent statements - surely you can just use "while" instead?..

At some point you have to draw the line. And simple, straightforward syntactic sugar for heavily used constructs - which is precisely what "a => a + 1" is relative to "function(a) { return a + 1; }", at least if you heavily promote the use of high-order functions elsewhere - is always worth including.