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]

I use Javascript as an Object Oriented Language.

While in Rome, do as Romans do. Unless you are stupid.

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.

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

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

[scdeimos]

CoffeeScript compiles to JavaScript but has a slightly saner object model for people coming from C++ or Java.

Yes, the lack of quality IDEs are a problem.

And the quality of Javascript code examples out there on the internet are just as bad as they are for every other language - so shouldn't be a new bad experience.

And, of course, every browser has their own little idiosyncrasies when dealing with Javascript and DOM, etc., so you're probably better off learning to use a decent library like jQuery that takes care of (most of) that for you.

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

[Anonymous Coward]

Visual Studio has nice Javascript support and Intellisense understands JQuery, so there is at least one professional tool and a great library you can use. Things like object inspection and breakpoints are all there and you will be surprised how quickly you can crank out code after a while. I completely agree with everyone that the lack of typing is pretty lame, but as a practical matter I don't find myself mixing up types very often, especially with the editor helping me. Good naming is pretty helpful. It's so easy to quickly run what you write that an iterative style of development emerges that can be effective because of quick test cycle. I've coded in all these languages, and the turnaround time in Javascript is really fun for playing around and trying ideas. CSS is also amazingly powerful and has no counterpart in traditional programming environments.

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

[defcon-11]

That's funny, because on the bookshelf next to my desk 'Effective Java' is sitting right next to 'JavaScript: The Good Parts". They are both very similar in that they outline the common mistakes made in each language due to bad design choices and they both offer recipes on how to work around them. Just in case you were wondering, 'Effective Java' is about 4 times as long as 'JavaScript: The Good Parts'.

Re:Going down in flames

[shutdown -p now]

It's common knowledge that Java is a pretty bad language as well. It's just that we had 15 years to write IDEs and other tools to serve as crutches for its deficiencies. JS hype, in comparison, is relatively new, so the best we've got is jQuery.

Re:Going down in flames

[Anonymous Coward]

That sounds like statist drivel right there.
Wrong is still wrong, you sappy crowd pleaser.

As for debugging and testing...meh on you. Browser inspection console is easy as pie. .

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

[tomhudson]

Lack of a proper re-processor and lack of compile-time type checking are the two big problems.

The preprocessor can be fixed by using the c preprocessor to handle things like macro expansions, #defines, and <include>s. (gcc -E). The lack of compile-time type checking ... well, that just is what it is - an inferior language.

Re:Going down in flames

[Anonymous Coward]

To put things in perspective, there is the "OO" way and there is the procedural way.

Most Javascript can be written either way. Java can not. C++ can but, most people do OO.

The problem is that if you come from a OO background (eg C++ or Java,) Javascript seems like a mess, and PHP seems kinda crappy.

If on the other hand you come from C, javascript is easy to pickup, because you're not distracted by the OO candies and boogers.

When you go straight from C to Java, you're likely to be frustrated by having to use OO when you just need things in the global scope.

If you use Perl or PHP (both of these languages overlap in significant ways) both also seem similar to Javascript.

So the logical way to do things is
If you are familiar with C, Javascript, Perl or PHP, switching between any of these languages is fairly simple.
If you are familiar with C++ or Java, then PHP, Perl, and Javascript seem somewhat convoluted.

My advice to people who want to get into programming is to start with C, get used to having to properly declare variables and prototypes, and then learn Perl, PHP and/or Javascript, and use the same declare and initialize variables for proper programming techniques.

There are other languages that are completely alien (Python, Ruby, Smalltalk, ObjC) to the C style programming rules used in C++, Java, Perl, and PHP. Generally switching between these two styles tends to be frustrating, but some programmers prefer the Smalltalk-like Object system over the C++/Java.

In my opinion Perl,PHP and Javascript is contaminated with OO when at some point the developers of the languages started listening to the OO developers. Overcomplicating the languages which were unnecessary for scripts that run for maybe 60 seconds at most. PHP is the least useful with OO, because it just wastes more and more memory and processing time without any real benefit. Perl's OO is useless when used as a web-front end for the same reason PHP is. If a program is to run longer than 60 seconds (eg constantly,) it should be written in a compiled language like C, C++, or ObjC. If it's designed to be written for the web, it should only be written in an interpreted language, because any benefit of compiling is lost if a mistake results in downtime or compromise.

Re:Going down in flames

[Anonymous Coward]

You can't pick up a new programming language, and expect to use it the same way you use an existing programming language. It just doesn't work. You have to learn to work with the abstractions provided, how to think effectively in the new language, and how to express what you want in that language in a way that other developers will understand (what the Python guys call idiomatic code). If you go into JavaScript with a Java mindset (or worse - a C++ mindset), you're going to make an enormous mess fighting the language, rather than working with it. Kind of like the old guys who manage to write Fortran in any language.

Admittedly, JavaScript has some warts, and you just have to get used to them. Tools aren't quite as mature as other languages, particularly Java or C# (I'd argue that C++ tools aren't really much better than JavaScript). Some of it's just weird, and takes time to get used to, particularly if you aren't used to functional languages.

Just look how stupidly difficult it is in JavaScript to implement even basic inheritance.

So? Class inheritance is a terrible idea, and you should never need to use it. Basically, inheritance breaks encapsulation. You only need it in a language like Java because it is sorely lacking in abstractions you can use. You have class inheritance and interface inheritance, and that's all. If you want any kind of polymorphism, it must be either inheriting from a base class, or implementing an interface. Since you can't reasonably do object composition in Java, and since most of the Java runtime libraries were designed in the early 90s, you sometimes have no choice but to use class inheritance. Doesn't mean it's a good idea.

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.

No, it isn't. In fact, I'd argue that it's impossible to do that, and still have something that's recognizably a Java or C++ program. You'd have to implement your own object system, with your own dynamic dispatch system, come up with some way to dynamically call methods which may not even have the right function signature without simply blowing up, and you'd lose your compile-time type checking. Good luck with that, and commiserations to the guy that has to maintain it.

You don't want to write JavaScript in Java any more than you want to write Java in JavaScript.

Well, it turns out that they can both be implemented very easily using the proper class support that both Java and C++ offer.

Rubbish. You can build a functor object (an object that behaves like a function, basically), but that's about the extent of it. It's using the wrong abstraction - you want a function, not an object. The functor can contain some of it's own state, but it can not capture variables, which is one of the more important features of closures. Functors get you some of the way there, at the cost of being a lot more difficult to use than just using a function reference. Why do you think C# and C++11 implemented lambda functions, and Java will be getting them soon, if they weren't necessary? They aren't mere syntactic sugar - they significantly change the language itself, and allow (limited) variable capture.

It's blatantly obvious that you don't understand first-class functions, or closures. If you don't understand those, there is no possible way that you could understand JavaScript. Suggestion - learn a functional programming language. JavaScript isn't a proper functional programming language, of course, but many of the common concepts from functional languages carry over to JavaScript, as well as modern C++, C#, and potentially future Java versions.

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 manua

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

[Chrisq]

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.

Actually lambda functions are difficult to implement in C++ (you need to use varargs hacks) and cannot be done without reflection in Java (assuming that you mean applying to normal functions and you don't mean just defining your own parameter list types).

Re:Going down in flames

[narcc]

You also NEED to aquaint yourself with jquery. Javascript is almost untolerable without it.

Ugh. No you don't. Run as far away as you can from that and the zillion other steaming-piles like it (underscore.js comes to mind here).

If you've ever asked yourself "how can I make my code less readable?" or "how can I over-complicate this simple problem?" then jquery is your answer.

You'll probably want a good whiskey supply to drown your sorrows after knock off time too. Javascript is bloody awful.

Stop using jquery and you'll find that half of your headaches are gone automatically. Javascript can brain-dead simple if you know how to use it -- and it can be a gigantic headache when you use it incorrectly. If you think jquery makes your life easier, you're clearly using it wrong.

Re:Going down in flames

[Anonymous Coward]

Thank you for this ( both the book & opinion ) information...

I personally have used some HTML/JavaScript in my embedded web server that runs on a very limited (32K) embedded system. And JavaScript saved the day for me, instead of spitting out lots of HTML, I turned to JavaScript and it did the necessary job. Yes it is a different language but I can not say that I dislike it. I accepted it as it is...

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

[narcc]

getting around Java's lack of multiple inheritance, or other shortcomings.

Lack of multiple inheritance is a good thing. I thought we all learned that lesson decades ago?

Java's type checking can be helpful at times,

Java's type system is a gigantic mess that causes more problems than it solves. It's ridiculous type checking is particularly irritating. (Why do you think people got so excited over generics? It was a solution to a problem that should have never existed!) As you say...

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. ("But, but, other people!" cry the uninformed! Well, they're uninformed.)

Back to JS, it would be nice if JS had a way to force a variable to always be a particular type, but it's easy to know ahead of time what type you'll have after an assignment. (It would also be nice if it had a freaking unsigned integer type, but that's a complaint that I have with other languages, Java included. Seriously, how did this get overlooked? It's the most frustrating thing ever.)

Re:Going down in flames

[Anonymous Coward]

You may find the following links to Java 8 "project lambda" interesting:

http://openjdk.java.net/jeps/109
http://openjdk.java.net/jeps/126
http://openjdk.java.net/projects/lambda/
http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html
http://cr.openjdk.java.net/~briangoetz/lambda/Defender%20Methods%20v4.pdf

Re:Going down in flames

[narcc]

Class inheritance is a terrible idea, and you should never need to use it.

Hear, hear! (Can you believe someone above was actually advocating multiple inheritance? Insanity!)

There are plenty of ways to write decent code in dynamically typed languages. They just aren't the same as how you write decent code in statically typed languages.

I'd accuse you of stating the obvious but, looking at the discussion here, it's apparently not obvious at all...

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

[Fusselwurm]

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.

Last I checked, server-side JavaScript seemed to be all the rage with the cool kids.

JavaScript was born for the browser ( and even has (horrible) features that only make sense in a browser ( try 'blah'.bold()), except that they dont), but that doesnt mean it is a bad language for all other purposes.

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

[Anonymous Coward]

> "Just look how stupidly difficult it is in JavaScript to implement even basic inheritance"

This is exactly what the parent was talking about. You come to the language with a preconception. JavaScript do not have class based inheritance, true, it have prototype based inheritance. So it is not hard difficult to implement inheritance in JavaScript since it is already there. On the other hand, if you try to implement class based inheritance in JavaScript, then you are doing it wrong.

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

[Anonymous Coward]

Chrome's builtin inspector has pretty damn nice tools for debugging and profiling JS.
I must say, I used to hate frontside WebDev, but it turned out I didn't know what tools to use and how to use them effectively.

Now if I could only tell Chrome to somehow "send the fixes I've made to the JS and CSS back to the server".

Re:Going down in flames

[narcc]

It's not 2002 any more. Had you avoided jQuery you'd know how much the web has changed and how simple it is to make complex things happen across the major browsersv:)

  Besides, you shouldn't have been doing "fancy UI stuff" with Javascript in 2002. I refused to even use JS until 2006 when I decided things were finally sane enough to invest my time in.

If you feel that JQuery is making things less readable, why not wrap the JQuery stuff in your own functions?

You can't be serious! Wrap an unnecessary (and bloated) library in a set of my own functions? Why not just write my own functions in the first place! I could cut out jQuery, reduce the size of my pages, and improve the codes performance.

Which is what I do, actually. Skipping the whole jQuery mess altogether!

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

[narcc]

did it touch you inappropriately?

You could say that. Dealing with the illegible garbage that other people produce with jQuery (often at the expense of simpler and more legible solutions) certainly feels like I've been violated.

As for cross-browser JS, that's been painless for many years now. Whatever benefits jQuery may have offered in the past are completely irrelevant today. Writing code that works across-browers is already ridiculously easy. jQuery is actually adding unnecessary complexity!

Re:Going down in flames

[Joce640k]

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.

This is the crux of the problem. People are trying to use JavaScript for real programs.

Re:Going down in flames

[Joce640k]

Nah. C++ has loads of stuff that you shouldn't use. Ever.

new[] and delete[] for example - all the fun of malloc(), none of the safety/automation of STL.

Re:Going down in flames

[Anonymous Coward]

You don't have a clue what a lambda or closure is, if you think C++ can do them with classes. There is absolutely no way on Earth you can make a C++ class wrap over local variables of a function and continue to access them after the function returns. Even if you the language did support that, the memory management issues of closures without garbage collection makes them a non-starter. I think your post is really showing your ignorance of functional programming, rather than highlighting any flaws per se. It is easy to do inheritance in JavaScript, and you are not restricted to C++ metaclasses either, you can pretty much define your metaclass too. But, hey, you're saying "what's a metaclass" now, so I'll stop.

Re:Going down in flames

[Anonymous Coward]

Wow, fellow Anonymous Coward, your post reads like you haven't used it enough to get used to it and you still have opinions about it.

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

Moving from Java to JavaScript is a big jump because you're gaining many abstractions that just don't exist in Java (and no chance they exist in C++).

>Just look how stupidly difficult it is in JavaScript to implement even basic inheritance.

It's easy to do so; but that's not the point, why are you trying to shoehorn traditional models onto a modern language? They have better abstractions than classes (hint: no customer ever wanted "basic inheritance").

>It's far easier to imitate JavaScript's prototype-based OO approach in Java or C++

How? No way you can do that as easily as emulating classes in JavaScript - since prototype-based languages are more flexible and thus adaptable to whatever you want. I'd like to see you do prototype-based OO in C++. It would make C++ a lot more palatable. Please do add a comment with the URL to it here should you do it - it would be really useful and help millons of people.

>Well, it turns out that they [lambdas, closures] can both be implemented very easily using the proper class support that both Java and C++ offer.

No, they can't be implemented easily there. I tried. C++ can't even do event callbacks, for heavens sake, and you want it to do proper closures. On second thought, it can't even do nested functions (normal functions!).

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

Yeah, as a frankenstein's-monster-style add-on instead of the basis of all computation. But better than nothing - and only a few decades late. But then, why should one use mathematics in a field that is basically applied mathematics, my bad.

>You don't have a compiler doing a lot of type checking automatically when you're using JavaScript.

Computers can only handle numbers. Whatever you do on a computer is in fact calculating numbers. If you want to kid yourself that it actually calculates fairies, go ahead - but please leave it in your head, not in the programming language.

>effort *basically implementing type checking yourself* within your JavaScript code.

You're doing it wrong.

Re:Going down in flames

[Forty Two Tenfold]

It took less time to write than it did to learn the equivalent bits of jQuery.

Yeaaaah...

You can't divide by zero.

Re:Going down in flames

[Anonymous Coward]

Our profession is to learn. And to learn to learn. Stop whining. Can't cope with changes and 'inferior' languages ? Here's a stack of burger-flipping applications.

Re:Going down in flames

[Assmasher]

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

I'm sorry, but you're simply giving credence to what he's saying with something like that.

I would never let one of my engineers check code in that looked like that (much less do it myself.) Talk about a lack of clarity, lol...

Re:Going down in flames

[Anonymous Coward]

Where "cross-browser" means "both IE4/5/5/7" and modern browsers.

We target IE8 and up, and of course Gecko and Webkit browsers, and we have very little IE-specific stuff in Javascript. Apart from some very specific things (like date pickers) we avoid jQuery like the plague.

Learning JS and jQuery is learning two different languages at the same time, two languages that have nothing in common, and can do the same things.

Re:Going down in flames

[Anonymous Coward]

Javascript isn't meant to be done like c++ or Java, so don't try!

He didn't say he was going to, you maroon.

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

[jimshatt]

Looks fine to me, and I'm not even a JavaScript guy. What would you let your engineers check in? (i.e. put your money where your mouth is)

Re:Going down in flames

[Anonymous Coward]

No it doesn't. Do you need to know the basics of the API? Of bloody-fucking-course.

Re:Going down in flames

[FlyveHest]

Why not?

Slap a two-three line comment in above that call that describes whats going on, and I see absolutely no reason to not use code like that?

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

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.

Re:Going down in flames

[JasterBobaMereel]

Go and have a look at Scheme or Haskell, and you will start to appreciate that the languages you know already C/C++/Java are nearly identical in comparison, and Javascript isn't so stange after all ...

It's a bit like saying you are worldly wise but have never left the USA, and you are new in Canada and it's very strange ...

Re:Going down in flames

[DrXym]

The problem with JavaScript / ECMAScript is that it's shapeless. It doesn't enforce any particular programming style, it doesn't offer much in the way of OO programming except poor man's prototypes, it's difficult to maintain, it's easy to break at runtime, it comes in multiple subtly broken dialects, and its usually invoked from multiple not so subtly broken browsers. Programming JS is an exercise in trial and error.

I'm not surprised that so many things attempt to work around JS as much as possible. AJAX libs attempt to hide the utterly arcane, often buggy ways of accessing the DOM. CoffeeScript attempts to reduce the bloat even further. And other tools like GWT, Emscripten attempt to do away with JS as a problem for the developer altogether. What all seem to implicitly admit is that once JS is employed not just as some HTML glue but as the application code, it becomes an unmanageable pig to develop against.

Re:Going down in flames

[TheRaven64]

a slightly saner object model for people coming from C++ or Java

Java has a Smalltalk-derived object model and C++ has a Simula-derived object model that have only one thing in common: that they both use classes (although they use very different definitions of what a class is). I shudder to imagine what kind of ugliness you get when trying to make something that is intended for people coming from either...

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]

If closures and lambda expressions were so easy to implement using basic inheritance, Java would already have it

Closures and objects are trivially provable to be equivalent - you can represent both in the same lambda calculus terms (and Simula and Smalltalk both implemented one in terms of the other - a Simula class is a closure that returns itself, a Smalltalk closure is an object). The problem is not the semantics or expressiveness in the theoretical sense, it's the syntax. The thing that makes closures useful in languages that have them is that they are less verbose to create than classes. You can create a Java class called Closure with an invoke() method, create a subclass of it for each call site, instantiate it, set all of the things you want to be bound variables as instance variables, and then pass it to something that will call the invoke() method (or some variant with different semantics). But no one wants to write code like that, because it's spectacularly ugly and verbose.

Languages like Clojure target the JVM and do exactly this kind of trick. They allow you to have closures in a language that uses the same underlying object model as Java. A big part of the reason that Java lacks them is that it was designed as a language for average programmers, and so intentionally omitted programming features that the designers considered were complex to use.

Re:Going down in flames

[Anonymous Coward]

I am currently getting paid to program in assembly. When I go home at night, I program in Java. I used to get paid to program in C#. I went and got certified in Java because that is the crowd I wanted to chill with over a hot cup of tea/coffee. I tried Python for awhile, but eventually I got frustrated with the lack of options it had. Even now, I get frustrated with how crazy complex the Java API is. More often then not, I find myself implementing something, then finding out the Java community already did the work for me and I just didnt realize it at the time.

The best poison is the poison you get paid to drink. Hence, assembly is the best language for me at this moment. Ive done C, Python, Java, Visual Basic, C#, and C++ professionally. Do whatever brings home the bacon. Dont worry about what the next trend is because if an employer is worth working for, then they will hire you based on your potential to help and improve their business, NOT based on what language you happened to program in last.

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

[hobarrera]

I can the standards, but some users will use wanna-be browsers developed by people who can't read standards. There's one called IE6 that's quite popular.

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

[hpoul]

Where is your point? If you know the underlieing technology you perfectly understand the code on first glance and it is easy to write..
Its like saying .. yeah, you need to understand the GC and parts of the jvm to know what the impact of my 5 lines of java have - so i write my own JVM.. i guess you suffer from NIH syndrome..

Re:Going down in flames

[AJH16]

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

This is what I don't understand about the direction of travel of web development right now. While eclipse does ok, there is not (IMHO) a single solid, good IDE for HTML, Javascript and CSS development that comes even remotely close to the ease and simplicity of just about any desktop display API I've ever seen. This includes some DOS based stuff for crying out loud. We've had this technology in one form or another for 15+ years and STILL don't have a user friendly ability to generate UIs and yet it's considered the grand future and even pushed by some in favor of native UI development on mobile. It's slow, over bloated, painful to write in, easily becomes unsafe, easily fails at run time, etc. Yet we continue to march forward because of browser lock-in and a lack of ability to actually update the system to address problems. I know it may sound fatalist, but I for one don't look forward to moving back to the stone ages of glorified terminal apps that have the additional limitation of being unable to receive a message from the main frame unless they initiate a message. The whole system seems like it is moving backwards in the name of progress.

Re:Going down in flames

[Gr8Apes]

I too have done the DOM and Ajax coding in the "old" days, even before Prototype really took off. I'd have to agree that writing cross-browser Ajax code is trivially simple.

On the other hand, JQuery does have some appeal in making some things easier.

Re:Going down in flames

[gbjbaanb]

separating program logic is the best advice for such a guy - don't try to write your application entirely in javascript, write big chunks of program logic in C++ (or whatever) and expose that as islands that you call for processing. Use the javascript for glue to bind the HTML and calling logic together.

Re:Going down in flames

[Anonymous Coward]

a) Reusability - it's not a library function. It's an application of library functions in a piece of UI logic. Sure, you could write "function create_hiders(hideable_class, hider_elt)", but it won't be used more than once in current project and it won't be useful for other projects - what if you want toggles after the element? what if you want element to be the toggle? what if?.. Sure you could generalize all these cases in one function, but then that function would be the problem, with hundreds LoC where 5 are enough.

b) "Defining a function inline to your statement" just calls for a plain "what" and demonstrates the problem with people migrating with preconceptions from other languages. It's called "anonymous function" and it's perfect for defining single use callbacks. Would you demand to write "function add(a,b) { var result = a+b; return result } function sum(array) { var result = array.reduce(add); return result }"? What's different here?

I'd say original sample somewhat lacks maintainability, but you don't need to go any more verbose than this.

Re:Going down in flames

[TooTechy]

I have to say that you both have points. jQuery can make things easier. BUT. It has huge memory leaks which will bite you really badly if you use it a lot.

I too have my own set of libraries for most things and still use them just because of the issues around jQuery.

I still use jQuery for some things though. The time consuming part was determining which parts area actually safe to use.

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

[multipartmixed]

The problem with that code is that it's not *readable*.

Code is not supposed to be read-only. It needs to communicate what it does, clearly, to the maintenance programmer.

Re:Going down in flames

[Anonymous Coward]

if you think that javascript is the future of the web then you are a gullible idiot and seriously susceptible to hype.

the reason html5 is not getting anywhere is because it's crap - and so are you!!!!

Re:Going down in flames

[Anonymous Coward]

This is exactly the same issues I have with JavaScript as well. Everytime I switched to a new lang, I gained something worth while, except for the crap JS is. Basic things like having to hand roll your constructors, loosing type safely, Generrics, etc, just to get access to the browser isnt a worth while trade for me. There are better dynamic langs out there, but unfortunately JS is the one that is well integrated into the browser and that is the only advantage it has.

Re:Going down in flames

[Anonymous Coward]

Well, when people come at Javascript as if it were C, C++, or Java, something had to be done in order to clarify just how to use the language correctly.

Re:Going down in flames

[Cro Magnon]

Well, shortly before I left DeVry, one of my classmates, who had already started on her first job, told me about ALTER in COBOL, and beyond using language that I don't normally hear from females, she advised me not to to use it. So, JS isn't the only language with parts that shouldn't be used.

Re:Going down in flames

[rock_climbing_guy]

To put things in perspective, there is the "OO" way and there is the procedural way.

Don't forget the functional programming way!

Re:Going down in flames

[Anonymous Coward]

The difference is that most of the obscure language features in C++ are actually useful. Having a powerful multifunctional tool is not a bad thing.

First of all, C++ is so large a language that practically no one knows everything about it.

The language constructs are described over 400 pages in the C++ standard. And the standard describes the language in the most verbose way possible. It's not so hard.

Re:Going down in flames

[Anonymous Coward]

Absolutely spot on.

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

[Anonymous Coward]

1. I understood what the code was doing immediately without looking at his description afterwards.
2. Let's see your code, also the documentation to go with it, as well as thousands of examples available freely.

Re:Going down in flames

[Tsingi]

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.

I'm not trying to use jQuery at all, nor criticize it. I have code of my own that I have been using for ages.

Re:Going down in flames

[Anonymous Coward]

I concur, only I would add that the uneasy feeling never really goes away - at least not for me.

Re:Going down in flames

[Anonymous Coward]

Cross browser AJAX is actually very complicated and the jQuery implementation is overly simplistic and will not work for a site where you are interested in performance.

There is one major problem with jQuery implementation.
It doesn't support flushing of the AJAX response. This is actually a very complicated problem with Internet Explorer being naughty again.

Re:Going down in flames

[yog]

Chrome also has a pretty good javascript console. I don't know how it compares to FF's, but for me it was a lifesaver.

Re:Going down in flames

[Anonymous Coward]

Besides, you shouldn't have been doing "fancy UI stuff" with Javascript in 2002.

He wasn't, he said it turned him off of it. Learn to read you fuckhead.

Re:Going down in flames

[spongman]

mismatched-typing issues are a tiny minority of bugs I've seen make it to production

that's a pretty big qualifier.

Re:Going down in flames

[trev.norris]

There are plenty of awesome books that clearly and concisely explain how to use JavaScript most efficiently. Off the top of my head, John Resig's two books "Pro JavaScript Techniques" and "Secrets of the JavaScript Ninja" would also have to be at the top of your "most widely-respected" list. "The Good Parts" has a small section explaining things that will cause programmers problems down the road. And it does this because the language is so flexible people who don't want to learn the language properly will hack together anything just to get past the "pain" of it all.

I've been coding javascript since 2002 and love the language. To quote Robin Williams, "People call these things imperfections, but there not. Ah, that's the good stuff." And that's the way it is. JavaScript has way more things right about it then there are wrong. Every language has its imperfections, and for some reason people are convinced that javascript is only that. Unless you code in a language full time for years, don't think you can speak authoritatively on it.

Re:Going down in flames

[narcc]

Are you from the past? IE6 is rapidly vanishing. StatCounter reported it as having 5% market share in the US and Europe way back in June of 2010.

You have a funny definition of popular!

Re:Going down in flames

[gknoy]

There are many times when an anonymous function or class is the simplest, idiomatic (in the language in question) thing to do.

Event handlers in Java and GWT frequently are anonymous inner classes, but it often ends up being easier to read than writing a custom class that handles each different event, and each different event source. I've done both, and railed against the anonymous classes at first, but now that it's the idiom, it's what I use -- it makes my code more similar to most of the sample and reference code out there, which means that other developers are more likely to understand what's going on.

Similarly, consider that since he was typing it from memory, he may have taken shortcuts that he might not use in production code, just as one often writes a Perl one-liner differently than one would a Real Program. Adding meaningful variables, and avoiding return-time evaluations might easily be something one could to in real code. Look at what he wrote less as a sample of how one SHOULD do things, but more of a demonstration of the power of the toolkit / API.

Re:Going down in flames

[xfurious]

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

$("#showhidecontrol") --- This call might not find the id="showhidecontrol" element. In which case it returns an *empty jQuery object*, not NULL. newToggleElement then would be a clone of the empty jQuery object, so its ok to use .click() on it (verified in the console). So this code is safe, and will *not* cause Javascript errors assuming jQuery has been loaded (safe to assume).

It is unclear because you do not understand the tools. I use jQuery every day and yes, it is absolutely better than stock Javascript (I know and understand the standardized DOM very well).

Reusability: This code is itself a function, the constituent parts of it do not provide a huge return in terms of reusability. Let's look at what happens if we define the lambdas here as non-inlined functions.

function hideableClickBehavior () {
// oh shit, what is hideableElement here? It (potentially) has no relationship to the element we are acting on!!!!
// hideableElement.toggleClass("hidden");
}

function applyHideableBehavior() {
var hideableElement = $(this); // wtf is "this", it makes no sense in this context now, but still works and is correct!!
var newToggleElement = $("#showhidecontrol").clone();
newToggleElement.click(hideableClickBehavior);
return newToggleElement;
}

$(".hideable").before( applyHideableBehavior );

What this produces is NOT reusable code, it is less clear code where the parts of the operation are not clear. Certainly other things CAN be done to what I have above to make it more "reusable", but at what benefit? If the app is designed correctly, there should be no other binding between an element event and the applyHideableBehavior() function, because this behavior is supposed to be unique. If you want reusability, REUSE THE 'hideable' BEHAVIOR, dont just blindly apply principles of reusability and expect it to give you a benefit in your software engineering endeavors.

Now stop trolling about stuff you don't understand.

Re:Going down in flames

[mcgrew]

Besides, you shouldn't have been doing "fancy UI stuff" with Javascript in 2002.

Depends on what you call "fancy". I used javascript on my old gaming site last century, but only as a last resort. I'd stick little surprised in, like there was an animated GIF of a Strogg, if you moused over it Sonic would run by, the Strogg seemed pissed that he didn't stomp the hedgehog, then Sonic ran from the other direction and SPLATT!!

Re:Going down in flames

[xfurious]

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

It is entirely obvious what is happening, because I am educated in using the frameworks we are looking at. I know the DOM, sometimes I have to use it when I can't use jQuery or MooTools or any other framework which has DOM CSS selectors. And that's the important part, DOM CSS selectors, which are brilliantly essential to efficiently writing flexible code in Javascript. Why? Because the structure of an HTML document DOES change, you need a query which will not break when someone sticks another layer of divs beneath the markup you are working with. CSS selectors allows for this. DOM traversal does NOT (yet, please standardize document.getElementsBySelector()!).

I think few of the anti-framework trolls here have delivered large-scale web software to a client before, let alone maintain it for a considerable amount of time. We do exactly that at my job, and jQuery is the LEAST of our maintainability concerns. In fact, its a shining glowy miracle in that it allows us to express our DOM location needs in an easy to understand, flexible way that allows for later changes to the underlying markup without significantly breaking the functionality of the javascript that is in place. The relevant DOM traversals here are expressed on a single line. This is not possible with the DOM proper until document.getElementsBySelector is standardized. And when that happens, yes, it starts to become feasible to skip out on frameworks and just use the standard DOM, but even then you are kidding yourself if you think you won't be writing twice as many lines of code, or just duplicating the same functions that the frameworks already have, except theirs have better code coverage, and much more real world testing than yours do. How egotistical do you need to be before you'll just accept someone else's perfectly good implementation of code you are about to write??

Oh, and No, you can't make your own versions of the functions, that defies the point. Besides, if your idea is so great, how come you haven't released it as open source and come back to Slashdot to troll people into using it because it's so much "better" from an engineering perspective?

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.

Re:Going down in flames

[xfurious]

Oh please don't.

I'm with you on preprocessing being *useful* for Javascript, though certainly far from a *big problem* overall. The biggest issue is doing separation of concerns by *file* since there is no way to import in Javascript. Thing is though is that this might as well be by design since doing such inclusions would cause network overhead. Hence the need for a server-side preprocessor right?

If only we had a PreProcessor which dealt with things like javascript and Html. Like, a Hypertext PreProcessor, or.... a Pre-Hypertext Processor. Or maybe a pretty red gem. I'm just saying, I think there are slightly more appropriate tools to use than the C preprocessor.

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.

Re:Going down in flames

[Assmasher]

There are many times when an anonymous function or class is the simplest, idiomatic (in the language in question) thing to do.

Yes, I agree, especially about it being idiomatic with JavaScript. It isn't idiomatic because that's how you should be doing in in JavaScript, it is idiomatic because tons of JavaScript programmers do it that way.

I also agree that it can be very simple, but it is also equally simple for it to not be an anonymous function. Is it as "easy" as doing it anonymously? No. Is it better from an engineering practices standpoint? Yes. Writing test cases for anonymous functions seems likely to be 'challenging' ;).

Event handlers in Java and GWT frequently are anonymous inner classes, but it often ends up being easier to read than writing a custom class that handles each different event

Event handlers in Java and GWT are often found to be anonymous, but they shouldn't be. Most of the time if you find people using anonymous functions/methods it is because they have not architected the solution to their problem properly to account for some edge case (especially in Java) or they are just lazy. I disagree pretty strongly that it is easier to read than writing a custom class that handles those events for many reasons, but mostly because of the opportunities for centralization of the code, re-use opportunities, and the ability to create tests for that class.

Now, all of that aside, there are surely cases where an anonymous function could/would be appropriate, but they are exceptions - not the general rule.

Similarly, consider that since he was typing it from memory, he may have taken shortcuts that he might not use in production code, just as one often writes a Perl one-liner differently than one would a Real Program

I can only comment on the code he/she actually submitted in support of "some of the most elegant web programming I have ever seen."

I think people (on both sides of the JavaScript debate) are mixing up the differences between what you can do with the language and what people tend to do with the language.

The code that was given was, imho, the antithesis of what a software engineer should produce. Does it mean it doesn't work? No. Does it mean it isn't clever? No. Does it mean it is buggy? No. It is, however, poor software engineering.

Re:Going down in flames

[Assmasher]

I'm sorry, but it really isn't worth my time to try and explain to you all that is wrong with your reasoning above, so I'll just address your first paragraph and your humorous 'functions.'

In which case it returns an *empty jQuery object*, not NULL. newToggleElement then would be a clone of the empty jQuery object, so its ok to use .click() on it (verified in the console). So this code is safe, and will *not* cause Javascript errors assuming jQuery has been loaded (safe to assume).

You are arguing that you don't need to bother checking if a valid object comes back because it won't throw up a runtime error. Wow, let's just push the error identification onto the user then, right? Lol. I mean, seriously, it is bad enough that you don't check to see if something is a valid operation when it very well might now be, but then it's ok for it to fail silently?

The rest of the arguments simply expose that you're not used to creating re-usable software components, or you're being disingenuous in your examples. You act as if you should be using this in the non-anymous function, you shouldn't. Everything used in that function should be passed to it unless it is a global exposed by a framework you are using. I will presume you're just being disingenous because I doubt you don't know how to write a function properly. Your really poor function attempts are indeed unclear in their operation because that's how you wrote them (again, presumably on purpose rather than through incompetence.)

Now stop trolling about stuff you don't understand

Stop pretending to be a software engineer.

Re:Going down in flames

[Anonymous Coward]

Hum, yeah, while it's not immediately obvious what it does, it only took me about a minute to step through each function. Then again, I've been working with jQuery for quite some time now.

That said, the code isn't really all that good - ids are supposed to be unique, and if you clone #showhidecontrol, you'll get some unexpected results at a later date. Also, it's not too obvious that the result from the function is appended before .hideable.

Probably better (clone may not even be necessary):
$(".hideable").before( $(".showhidecontrol").clone() );
$(".showhidecontrol").live("click", function(){
    $(this).next('.hideable").toggleClass("hidden");
});

This way, you're not nesting functions inside functions, and it's more obvious that .showhidecontrol has a 'onclick' event associated with it. It's a tad bit less precise (if .hideable gets moved around a lot, next('.hideable') may not find the correct .hideable element.

Re:Going down in flames

[Anonymous Coward]

This is a brilliant statement of the problems with JavaScript, and they're mind-boggling for a language that's there to support dynamic content in an enviroment where you want things to just work. It may've been fine for shell scripting, but a more concise language would've made developing for the browser so much less painful.

Re:Going down in flames

[Maudib]

"which is why server style Javascript has never caught on, "

Come on man, really? Its kind of taking off now.

Re:Going down in flames

[Brian Feldman]

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.

[Citation needed]

Boo-hoo, it is very hard to promote variables to final scope, or, if they need to be modified, as a variable in the enclosing object instance. You want complete elimination of type-checking of arguments? You think that's critical? Ludicrous.

Re:Going down in flames

[Brian Feldman]

This is the second post I've read in this article's discussion where the author claims you need lambdas in Java because you can't inherit variables otherwise. Try using final and modifying the actual declaration scope (putting it in an object, not the stack) if you need to truly modify something by value.

Re:Going down in flames

[tomhudson]

Doing it on the server or in the client is a dumb idea, because you get a lot more overhead on each page load, you have to transmit more bytes, you don't get to look at the source until you run it through the server, and you don't get nearly as much code reuse.

Don't knock the c preprocessor - every programming language could use the same abilities. Especially the crudfest known as java.

Re:Going down in flames

[TheCouchPotatoFamine]

jquery is quite awesome. Sounds to me like your a curmudgeon! Is it comfy, knowing that everyone will toil as hard as you do to produce results, once we give up our tools so you can "not have headaches" (i.e. not have to understand a thing before commenting on it?)

Re:Going down in flames

[TheCouchPotatoFamine]

Long variable names are the gift of (oh i don't know..) the 80's? Who in the hell thinks "var a" is better then var dictToStoreFirstAndLastNameLookup?

if you like "var a" better, may i humbly suggest you don't give a rats ass about other people.

Re:Going down in flames

[xfurious]

Doing it on the server or in the client is a dumb idea, because you get a lot more overhead on each page load, you have to transmit more bytes, ...

There is no network / byte transmission overhead when you do it on the server :-)

you don't get to look at the source until you run it through the server

Yes, but the C preprocessor has the same issue as with using a server-side language... I think maybe what you are thinking is doing a "compilation stage" on Javascript, ie writing in nice separated files and then using a preprocessor to create a finalized version, maybe top it off with some minification. I can dig that.

and you don't get nearly as much code reuse.

Hrm, I don't know about that. Choice of preprocessor isn't really going to limit your reusability.

Don't knock the c preprocessor - every programming language could use the same abilities. Especially the crudfest known as java.

I hear that. It's definitely true that Javascript needs some kind of preprocessor since network transfer is so expensive given the architecture.

Re:Going down in flames

[lennier]

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?

Hmm? You've just described the essence of functional programming (anonymous closures returned by functions-as-evaluations). Perhaps you don't like FP or consider it strange, but I'm not sure you've made a case that functional programming is any less disciplined than imperative object-oriented programming, or less suited to large-scale programming. FP predated OOP as a programming style, after all, and it's based on a far more rigorous mathematical foundation (I'd be interested to see any clear widely-accepted definition of OOP at all, let alone a mathematical one!)

Re:Going down in flames

[tomhudson]

Doing it on the server or in the client is a dumb idea, because you get a lot more overhead on each page load, you have to transmit more bytes, ...

There is no network / byte transmission overhead when you do it on the server :-)

Doing it locally during development, then loading the finished product on the server results in the same amount of data being transmitted from the server as if it were done every time on the server - but the server then doesn't have the overhead of doing the macro substitutions, includes, etc. It's the same problem as with those stupid "smarty templates" - 39 includes on every page load, just for the templating system. That's insane.

you don't get to look at the source until you run it through the server

Yes, but the C preprocessor has the same issue as with using a server-side language...

No it doesn't. The pre-processor just recursively expands macros and does includes, then outputs an ordinary text file. Instead of uploading 20 files, upload just one. BTW - It doesn't call the c compiler at any stage - think of it as a general-purpose text macro processor.

I think maybe what you are thinking is doing a "compilation stage" on Javascript, ie writing in nice separated files and then using a preprocessor to create a finalized version, maybe top it off with some minification. I can dig that.

That's IS the c pe-processor - except that the c preprocessor can also do macro expansion. Macro expansion, esp. conditional macro expansion, is handy. For example, stick a #define DEBUG in the code and then some #ifdef DEBUG // #endif, and you don't have to have any flag variables ending up in your production code.

BTW - the "minification" that's done by programs like yuicompressor sucks. Replacing only local variables is NOT the way to go. Here are the stats from my current home-made "minifier" - encoding global variable and function names gives an additional 40% off.

and you don't get nearly as much code reuse.

Hrm, I don't know about that. Choice of preprocessor isn't really going to limit your reusability.

Well, NOT having a pre-processor, and not being able to do condtional includes at development time, will tend to limit code re-use compared to not having a pre-processor. And the best part is that with a pre-processor and a bit of fancy perl-fu, you can use the same #includes for both javascript and php.

Don't knock the c preprocessor - every programming language could use the same abilities. Especially the crudfest known as java.

I hear that. It's definitely true that Javascript needs some kind of preprocessor since network transfer is so expensive given the architecture.

It's developer time that's expensive - and the way that people build up these huge pyramids of includes on the server is a real performance hit - especially since you can't do a global substitution on the functions and variables if each file is a separate piece of work.

You also end up including a lot of extra junk on every page load because "that's how it's built". What a waste.

Of course, there are people who are going to complain that encoding the function and global variable names is "wrong" because the code is a lot harder for them to steal^Wlook at - but hey, if it was hard to write, it should be hard to steal, right? :-)

Re:Going down in flames

[Assmasher]

I disagree completely. Programming an imperative language sloppily in such a way that it makes a logical representation that barely looks similar to functional programming (Haskell-ish shall we say) in no way connotates an advantage.

You also seem to be missing the point the original code submitting was making. He/she was suggesting that this code was an example of elegant web programming, lol.

Hell, people who want to embrace functional programming in JavaScript are more likely to agree with my assessment of the code. One of the advantages to using a functional programming style is abstraction and code reuse. Functional programming methods stand up better over time in a code base because they're implicitly more likely to be agnostic of state.

Re:Going down in flames

[Anonymous Coward]

As soon as you clone that element you have multiple elements with the same id, which is NOT, repeat NOT, a good thing. id's are to be unique. Instead, let's do this:

var hideables = document.getElementsByClassName('hideable');
var control = document.getElementById('showhidecontrol').cloneNode(true);
control.removeAttribute('id'); /* Still undefined behavior, but all the browsers I know of won't break or act weird afterwards */
for (var i = 0; i hideables.length; i++) {
        var new_control = control.cloneNode(true);
        new_control.addEventListener('click', function () {
                hideables[i].classList.toggle('hidden');
        });
        hideables[i].parentNode.insertBefore(new_control, hideables[i]);
}

Admittedly it isn't as beautiful as the jQuery nor as declarative. But it's not like it's something /disgusting/, and if your project has a NodeList.forEach (and if you do any interacting with the DOM you probably do), it gets even less uglier. Modern browsers pretty consistently implement the DOM. DOM incompatibilities were a a problem. 10 years ago.

Re:Going down in flames

[Anonymous Coward]

var hideables = document.getElementsByClassName('hideable');
var controlStamp = document.getElementById('showhidecontrol').cloneNode(true);
controlStamp.removeAttribute('id'); /* Let's not have multiple elements with the same id, mmkay? */
for (var i = 0; i hideables.length; i++) {
        var hideControl = controlStamp.cloneNode(true);
        hideControl.addEventListener('click', function () { hideables[i].classList.toggle('hidden'); });
        hideables.parentNode.insertBefore(hideControl, hideables[i]);
} /* With a NodeList.forEach, this code becomes less ugly. */

Re:Going down in flames

[Octayn]

var hideables = document.getElementsByClassName('hideable');
var controlStamp = document.getElementById('showhidecontrol').cloneNode(true);
controlStamp.removeAttribute('id'); /* Let's not have multiple elements with the same id, mmkay? */
for (var i = 0; i < hideables.length; i++) {
    var hideControl = controlStamp.cloneNode(true);
    hideControl.addEventListener('click', function () { hideables[i].classList.toggle('hidden'); });
    hideables.parentNode.insertBefore(hideControl, hideables[i]);
}
/* With a NodeList.forEach, this code becomes less ugly. */

Re:Going down in flames

[Anonymous Coward]

If you use windows, Visual studio + IE is best debugging environment for javascript debugging. Chrome debugger has an upper hand when it comes to event debugging, but for everything else VS+IE is better.

There are also javscript compilers available ('Closure' to name one) which sometimes help with huge javascripts.

Re:Going down in flames

[Anonymous Coward]

In GP's defence, JQuery handles nonexistent objects itself.

FWIW, it's one of the things I dislike most about JQuery (along with redefining "this" all the time). If an object may not exist that is clearly a problem that should be handled, not hidden.

Re:Going down in flames

[hobarrera]

Ok then: IE7. It still has lots of issues. I've no idea about IE8 or later though, but I expect something similar.

Re:Going down in flames

[catbutt]

Ok, so you've basically said Javascript sucks so just get used to it. I think that is excellent advice if the goal is for him to be miserable.

There is lots of cool stuff in Javascript that isn't in C++, I started with C and then C++ myself, and I find Javascript incredibly liberating. I'm not going to go through all the different things I like about it, others have done that before. My only point is that treating it so negatively is, from a psychological point of view, the worst kind of advice.

Re:Going down in flames

[Anonymous Coward]

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

Whay has this been marked as Funny? It's not funny, it's saddly very true!

Re:Going down in flames

[julesh]

I also agree that it can be very simple, but it is also equally simple for it to not be an anonymous function. Is it as "easy" as doing it anonymously? No. Is it better from an engineering practices standpoint? Yes. Writing test cases for anonymous functions seems likely to be 'challenging' ;).

Writing test cases for a nested function is likely to be just as challenging, yet the function I wrote *must* be nested, because it is required to have access to a copy of an outer-function local variable. That function can't be moved to an outer scope because it is necessary that the variable is bound to the instance of function invocation (i.e. it is a closure).

I'm yet to hear one good argument why the function shouldn't be defined inline. Just dogma saying not to do it. Well... justify it.

The code that was given was, imho, the antithesis of what a software engineer should produce. Does it mean it doesn't work? No. Does it mean it isn't clever? No. Does it mean it is buggy? No. It is, however, poor software engineering.

I contend that you're only saying that because you're unfamiliar with the environment. To anyone who knows it more than moderately well, what I wrote is clear, obvious, and the natural way of doing it. What other way should it be done?

Re:Going down in flames

[julesh]

Don't define functions inline of your statement.

Why? What is the negative consequence of doing so. If the function only needs to be referenced once, what is wrong with defining it where it will be referenced? It is more direct, and makes the action of the call to click() clearer.

Don't perform evaluations in your return statements.

Why? In what way is this:

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

clearer than

return $("#showhidecontrol").clone().click(function () { hideableElement.toggleClass("hidden"); })});

?

Avoid calling methods/functions on objects via the return of another evaluator.

Why? The API is a fluent API, specifically designed to allow this. Why not use this feature? Are you saying that respected programming writers like (e.g.) Joshua Bloch and Martin Fowler are wrong to recommend this style?

The code sample he provided is counter to reusability

I'd say it's very reusable: I can simply include this code fragment on any page I want hideable elements on, and it's reused. If necessary, I can wrap it in a function. If I wanted to make it more reusable, it wouldn't be hard to turn it into a jquery plugin, so then all I'd need to do is $(".hideable").addHideControl();

But in the end, how reusable do you need a 3-line code fragment that was written in less than 5 minutes to be?

readability

There are a lot of people who'd disagree with you there. Yes, you need to be vaguely familiar with jquery to understand what I wrote, but if you aren't familiar with the tools I'm using, what are you doing trying to maintain my code?

unsafe in that it doesn't evaluate possible nulls

There are no possible nulls. $(selector) is defined to always return a result set (which is possibly empty). The clone() method always returns a copy of the object set it was called on. The click() method always returns the object it was called on.

and arguably impossible to debug

I was debugging very similar code only yesterday, and didn't find it even remotely difficult.

Re:Going down in flames

[julesh]

You are arguing that you don't need to bother checking if a valid object comes back because it won't throw up a runtime error. Wow, let's just push the error identification onto the user then, right?

This is not an error condition that could plausibly occur at the user level. For it to happen, the referenced element would have to not be defined on the page, yet the page completed loading without error. Any form of acceptance testing will catch the possibility of such a condition before deployment.

And even if it does, what's the cost? A feature stops working, gracefully, because the method used to integrate it into the page was intentionally one based on the principle of graceful degradation. The controls to hide blocks of text don't get added, so the user can no longer do this. This is clearly not the end of the world, and it would probably be worse to bother the user with an error message than do nothing.

The rest of the arguments simply expose that you're not used to creating re-usable software components, or you're being disingenuous in your examples. You act as if you should be using this in the non-anymous function, you shouldn't. Everything used in that function should be passed to it unless it is a global exposed by a framework you are using.

Doing so would requires 10 or 20 lines of code defining new objects, setting fields in them to appropriate values, and generally associating objects with their dependencies, along with creating functions that call back to methods in those objects via closures (not an inbuilt feature of the language, unfortunately, as the language is designed to use closures in places where other languages might use callback objects). As you're a software engineer, I assume that you're aware of the finding that the cost of code both in terms of time to originally write and time required for maintenance over the life of the project is proportional to the number of lines, regardless of how many features those lines implement? You've just multiplied the cost of this little feature by 3-6 times.

Your really poor function attempts are indeed unclear in their operation because that's how you wrote them (again, presumably on purpose rather than through incompetence.)

He wrote them that way because that is the natural way of writing them in the environment. How do *you* write javascript callback functions? The typical OO approach of putting them in an object simply doesn't work properly because of the fact that js callbacks are in many cases not made to the object you expect. This problem is hardly unique to jquery, or indeed my code.

Re:Going down in flames

[julesh]

Your code doesn't work on Internet Explorer prior to version 9, or Firefox prior to version 3. The jquery code I posted will work on IE6 or Firefox 1.

Re:Going down in flames

[samdutton]

As far as debugging tools. Don't bother with Chrome. It's nearly worthless for Javascript testing or debugging.

The Chrome Dev Tools are at least as good as Firebug now -- as this blog post shows.

Re:Going down in flames

[Assmasher]

Writing test cases for a nested function is likely to be just as challenging, yet the function I wrote *must* be nested, because it is required to have access to a copy of an outer-function local variable

The very fact that you're trying to argue that it is just as easy to write test cases for anonymous functions as it is for non-anonymous functions is ridiculous. Trying to artificially constrain the non-anonymous function to being nested is also disingenuous.

You also seem to be ignoring that it is clearly and unequivocally simpler to test a function that belongs to one object/class/namespace and is used in multiple locations than it is to test functions on a per usage basis as would be the case of an anonymous function.

Anonymous functions do have important usage cases, i.e. when you must manage a very particular scoping issue.

The reason that JavaScript code is littered with them is because people find them convenient. Plain and simple.

I contend that you're only saying that because you're unfamiliar with the environment. To anyone who knows it more than moderately well, what I wrote is clear, obvious, and the natural way of doing it. What other way should it be done?

I contend that you don't understand what the word "elegant" means, much less what good engineering practices are.

Are you familiar with any other programming environment in a professional capacity? It seems highly doubtful. I am familiar with the environment, as well as many others. It's why I can recognize the problems that you obviously don't see.

Re:Going down in flames

[Assmasher]

FFs, you really don't understand basic software engineering principles.

Don't confuse that with someone saying "you can't program" - they are different things.

How are the two ways you demonstrated for returning different in clarity? They basically aren't. They're total crap either way because of the rest of your "elegant" code, lol.

Why is it a bad practice to perform evaluations in your return statements if you are a software engineer? Because anyone who has to debug your glob of strung together operations will need to actually change the code in order to evaluate its operations. This is bad. Is it a felony? No. Is it better software engineering to already have code in place that can be debugged without changing any code? Does this mean that you cannot (not to be confused with should or should not) perform multiple evaluations in a single line of code? Of course not, but the goal should be to avoid it. Not celebrate it as "elegant."

All of the rest of your "points" are exactly the same, poor engineering practices (some laughably poor such as the one where you claim the code is "very reusable" because you can cut & paste it on any page you need it on!)

One of your statements hints at the fundamental difference between the way programmers and software engineers think...

Yes, you need to be vaguely familiar with jquery to understand what I wrote, but if you aren't familiar with the tools I'm using, what are you doing trying to maintain my code?

That, in a nutshell is the difference. It isn't "your code" that somebody else has to maintain. It belongs to the company, or the client.

If you want to write code just for yourself, nobody care how badly engineered it is; but, if you're writing code for someone who is paying you to do it, you should make every reasonable effort to make it easy to debug, reuse, and extend.

The difference between a programmer and a software engineer in this case is that their definition of "reasonable effort" is apparently vastly different.

I was debugging very similar code only yesterday, and didn't find it even remotely difficult.

- The staggering naivete this statement exhibits is amazing. Is every programmer working on a project going to have the same skills? The same levels of familiarity with a giving API or framework that you do? Is everyone just supposed to be you? Lol.

Re:Going down in flames

[Assmasher]

This is not an error condition that could plausibly occur at the user level. For it to happen, the referenced element would have to not be defined on the page, yet the page completed loading without error. Any form of acceptance testing will catch the possibility of such a condition before deployment.

Wow. Staggering. You are able to predict the way different browsers on different operating systems will work in the near and distant future!

You also have an incredible amount of faith in what you termed "acceptance testing" - in other words, let the user (the acceptance tester) catch the error.

And even if it does, what's the cost? A feature stops working, gracefully, because the method used to integrate it into the page was intentionally one based on the principle of graceful degradation

You seem to continually getting confused between talking about practices and talking about the specific operations you put in your "elegant" line of code. Who cares what the particular line of code does, I don't. What I am pointing out about your line of code are the bad practices you are exemplifying as "elegant."

What's the cost? Time, money, frustration. People who code the way you do in your example make things more difficult for anyone else to find, fix, and test problems. The cost in one anonymous single line "elegant" function? Minimum, but measurable. The costs when someone like you have been working on a product for a long time, littering the code base with your 'elegance'? Large.

As you're a software engineer, I assume that you're aware of the finding that the cost of code both in terms of time to originally write and time required for maintenance over the life of the project is proportional to the number of lines, regardless of how many features those lines implement?

Actually, you've convenient left out the impact of good engineering practices on both the time to implement or extend, and the effort to support and maintain. You're apparently a "pound of cure" kind of person. Maybe you're just used to dealing with small projects, such as a series of web pages. So that you find that cutting corner on engineering gives you a better profit margin. It doesn't unless spending more time fixing things is part of your business model.

You're really not going to be successful trying to argue that making code less testable and maintainable is a good thing; although you keep pretending that someone is saying the code is untestable and unmaintainable which are, of course, different things. Any code is testable in some fashion, and any code is maintainable is some fashion.

The typical OO approach of putting them in an object simply doesn't work properly

Why do they have to be in an object? This isn't some OO approach to engineering practices. You shouldn't write C code that looks like the example provided. It would be just as bad.

Re:Going down in flames

[julesh]

Are you familiar with any other programming environment in a professional capacity? It seems highly doubtful.

Yes. I have programmed professionally in C, Scheme, CMU Common LISP, Perl, C++, Java, C#, PHP and Python.

Have you ever programmed professionally in a functional environment? It seems doubtful, as you don't seem to appreciate the fact that functional languages (of which Javascript is an example) demand a different programming style to traditional imperative languages.

Re:Going down in flames

[julesh]

Wow. Staggering. You are able to predict the way different browsers on different operating systems will work in the near and distant future!

No. I allow my library providers to abstract browser behaviour and trust that if any browser behaves significantly differently in future (notably in this case violating the W3C recommendations for the DOM API) that the library will adjust for this. This is one of the advantages of using the libraries you are arguing against.

You also have an incredible amount of faith in what you termed "acceptance testing" - in other words, let the user (the acceptance tester) catch the error.

Err.. no. By "acceptance testing" I mean an automated test in an environment like Selenium or something similar that is run on every code check-in with all target browsers and which won't allow anyone to make modifications to the code while a test is failing.

You seem to continually getting confused between talking about practices and talking about the specific operations you put in your "elegant" line of code. Who cares what the particular line of code does, I don't. What I am pointing out about your line of code are the bad practices you are exemplifying as "elegant."

While you appear to be making a lot of assumptions about the practices I apply to my work on the basis of a three-line code example which you haven't been able to identify any *actual* problems with, only potential problems that don't apply in the specific circumstances we were discussing.
Given this situation the actual operations performed by the code in question seem particularly relevant, as that code is all you have to go on in making your assessment.

And you still haven't justified why you believe any of the following are bad practices:

* use of closures (which, if it is a bad practice, means the entire field of functional programming is apparently doomed to failure)
* use of fluent interfaces (which, if it is a bad practice, means that several prominent and well-respected writers on software engineering best practices are completely and utterly wrong)
* reuse of behaviours based on html element classes (which, if it is a bad practice, means that the approaches suggested by the W3C among others are at best misguided) rather than methods that rely on modifying programmatic behaviour (e.g. code inheritance).

I'm open to any rational argument. Please, point me in the direction of any such argument, particularly any research papers that justify the notion that these practices result in code which is harder to maintain or reuse than the practices you appear to believe are the only valid way to write software professionally.

You're really not going to be successful trying to argue that making code less testable and maintainable is a good thing

I'm not attempting to argue any such thing. In fact, I'm claiming that:

* my code is just as testable as any equivalent code (I know because I have trivially written tests that ensure that code exactly like this works as specified)
* my code is as maintainable (or more so -- the abstraction of DOM operations into a library enables easier maintenance in the event that an issue is identified where some browsers do not correctly support those operations) as any equivalent code that I've seen suggested, including the variations posted in this thread (most of which fail to work on older browsers that are supported perfectly adequately by the code I posted).

The typical OO approach of putting [variables required by a callback function] in an object simply doesn't work properly

Why do they have to be in an object?

Because the environment only provides two viable approaches to passing such values to callback functions:

* fields in an object
* values in a closure

and you were objecting to the use of closures, so I assumed you were proposing to use objects in their place. If you have another approach, please enlighten me.

Re:Going down in flames

[Assmasher]

Yes, I have, and yes, I agree that they do; however, a functional approach doesn't mean scattering anonymous functions throughout your code and then calling it elegant and re-usable because you (a)find it clear and you (b)can cut and paste the code wherever you need to re-use it.

Re:Going down in flames

[Assmasher]

No. I allow my library providers to abstract browser behaviour and trust that if any browser behaves significantly differently in future (notably in this case violating the W3C recommendations for the DOM API) that the library will adjust for this. This is one of the advantages of using the libraries you are arguing against.

How on earth am I arguing against libraries? Lol. I'm arguing against you relying on the user catching the error, and acceptance testing catching the error, and your "staggering" assumption that these errors are '...not error conditions that could plausibly occur at the user level...' (I pluralized your quote.) You're literally arguing that you don't have to account for these types of errors because (a)they could not plausibly occur at the user level and (b)they would be caught at acceptance testing. Well, which is it? Will they be caught by users at acceptance testing or not? Acceptance testing has to be performed as an end user would experience, so if it isn't plausible that these errors could percolate to the user, how would acceptance testing catch them?

I find it a little disengenous to suggest that I'm arguing against libraries because I think you're being cavalier with error handling.

Err.. no. By "acceptance testing" I mean an automated test in an environment like Selenium or something similar that is run on every code check-in with all target browsers and which won't allow anyone to make modifications to the code while a test is failing.

I'm sorry but unless you're referring to hardware black-box testing, acceptance testing involves the customer whether it is user acceptance testing or automated in some fashion. What you are describing is regression testing.

While you appear to be making a lot of assumptions about the practices I apply to my work on the basis of a three-line code example which you haven't been able to identify any *actual* problems with, only potential problems that don't apply in the specific circumstances we were discussing.

You're really making an effort not to "get it." I have identified actual problems with your idea of "elegant." You simply seem to ignore them. Nobody said the code doesn't work, but your approach to writing elegant code has clear and objective software engineering weaknesses which I have described to you at length. It doesn't mean you don't know what you're doing, it doesn't mean it doesn't work perfectly, it does mean that a codebase littered with "elegant" coding like you provided is problematic (again, for the reasons I have already proscribed.)

Given this situation the actual operations performed by the code in question seem particularly relevant, as that code is all you have to go on in making your assessment.

Indeed, and that assessment is about your claim of "elegance."

And you still haven't justified why you believe any of the following are bad practices:

I didn't claim that closures are bad practices, I claim that the way that you use an anonymous function without any context as to why you need and call it "elegant" is a poor software engineering choice.

* use of closures (which, if it is a bad practice, means the entire field of functional programming is apparently doomed to failure)

A bit melodramatic are we? I'm somehow against closures because I believe you're using an anonymous function in a line of code with multiple evaluations and disagree totally with you that it is "elegant."

* use of fluent interfaces (which, if it is a bad practice, means that several prominent and well-respected writers on software engineering best practices are completely and utterly wrong)

I think an objective objective observer would find the mess you posted simply method chaining. Maybe you should read up more on what the purpose of a fluent interfa

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

[wisnoskij]

Oh I would not say that at all.
And even if you did, it still takes care of all of that annoying cross browser compatibility, OO, and other hard parts of JS.

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

[wisnoskij]

Well HaXe in particular is designed from the ground up to compile to other languages.
I think because of this it has a lot of benefits over a simple converter.
I personally have never used it, but have both seen and heard about it a lot, and it looks so amazing for web dev.

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

[Jason O'Neil]

I use haxe and I thought I'd comment here.

While you do have to learn your way around the native APIs I find I can avoid writing pretty much any "native" javascript - so you don't have to learn the intricacies of the syntax, just the environment you'll be working with - and the compile time errors will help you avoid syntax errors anyway.

As for debugging, the JS output is usually similar enough that info the debugger gives you can be translated back, but it is definitely slower. Both Chrome and Firefox are planning support for "source maps" - which map the JS output to the original language source. The haxe community is pretty keen to support the appropriate maps as soon as these features land... which should make it all a lot easier.

(Disclaimer: don't work for anyone haxe-related, just a user and a fan)

Re:A language that compiles to JS

[wisnoskij]

I think the real point of his request is to come up with some better ways of programming JS, he just did not realize that you don't have to and should not learn JS to do this.
JS is a poor language with horrible compatibility. You are either a JS guru or you should entrust the hard stuff to the experts and use their tools.

Re:A language that compiles to JS

[leptons]

Javascript is NOT a 'poor language' with 'horrible compatibility'. Your statements are the hallmark of a troll. You do not really know what you are talking about.

Re:A language that compiles to JS

[bradleyjg]

GWT is great, but unfortunately the team at google has a) been decimated in favor of dart and b) in any event has/had a really short attention span.*

The project is nominally open source but AFAIK all the committers are google.com. The eclipse development mode is increasingly buggy as attention is diverted to the new source map method of debugging they are cooking up. Plugins for Firefox come out just in time for the next release.

As much as I love the concept and much of the implementation, I don't know that I wan't to risk devoting to much more resume space to a technology that may be a dead end.

*Seriously - read the release notes for the dot releases since 1.6. Every version there is a completely new preferred way of doing things. Bugs filed against anything but the latest and greatest paradigm languish forever.

Re:A language that compiles to JS

[Pseudonym]

And thirding. I wouldn't say it's "one of the nicest GUI libraries", but if you're a Java person who wants to write Javascript, it's by far the cleanest option.

Re:A language that compiles to JS

[narcc]

it still takes care of all of that annoying cross browser compatibility, OO, and other hard parts of JS.

Cross browser compatibility is ridiculously easy, you don't really need a tool to help you these days.

OOP should be avoided at all costs -- but that's in any language :) Javascript's prototype based object system is different enough from the "common way" (think: c++, Java, c#) that, if you've bought in to the OO hype, that trying to apply what you "know about OO" to JS is going to guarantee failure.

Besides, using one language and translating it to another is almost guaranteed to generate bad (or completely illegible) code in the target language. Just learn to use the target language effectively in the first place!

JS is ridiculously simple to use. I have no idea why so many people seem to struggle with it. My only guess is that they're trying to force it to act like Java or C# and (predictably) failing miserably.

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.

Re:A language that compiles to JS

[DrXym]

GWT's GUI is sitting on top of HTML so it's basically widgetized HTML elements. Some of the layouts are also not without their own dangers in terms of styling and stuff. For example the vertical / horizontal panels use html TABLE elements so you can easily find that some things you would expect to work don't unless you use another kind of layout.

Re:A language that compiles to JS

[Zaatxe]

From your sig:

Troll is not a replacement for I disagree.

You are wrong! "Score:-1, Troll" for you!

Re:A language that compiles to JS

[Anonymous Coward]

Try CoffeeScript. It's amazing. I have a C++ and Python background and had huge problems with JavaScript in general and especially with the object orientation. CoffeeScript transcompiles very nicely to JavaScript and you can use all JavaScript libraries within CoffeeScript. It's very easy to learn and for me the most efficient and enjoyable language I have used so far. You can do everything with it that JavaScript can do and it is easy to debug the transcompiled code.

Re:A language that compiles to JS

[arielsom]

A few years back I was in the same situation as the OP. I tried JS/HTML and there's no getting around it, the developer experience, the tools, the kludges you have to deal with are horrible. You can try to hide some of the suckiness with jquery and the like, but it's like sweeping dust under a carpet. It's still there, it's just that you have it isolated.
Flash was cool then so I moved to Flash, and though it has it's faults it's light years ahead of JS. Now things have changed so I wouldn't recommend going Flash anymore, but Haxe could alleviate the pain.
If you enjoy writing elegant code with a good IDE, stay away from the web unless you really need to. I decided to do web stuff anyway because of business reasons, but I do sometimes miss the Java work I used to do.

Re:A language that compiles to JS

[wisnoskij]

It is ridiculously easy to use, but almost impossible to use well.
And "OO hype"? Because reusable and maintainable code is overrated?

Re:A language that compiles to JS

[Paradigma11]

I can recommend http://www.websharper.com/home
F# and asp.net integration.
they went open source a month ago. so far i am really impressed by it(formlets...).

Re:A language that compiles to JS

[yog]

Fortunately, GWT will be around for a while, and is not competing in some way with dart, which is intended to be a javascript replacement.

http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html

They said that the GWT team is working on dart, which doesn't seem like a contradiction or a condemnation of GWT (although it might take time away from improving GWT). But since GWT's been around since at least 2008, there's starting to be some aftermarket widgets and improvements floating around out there.

I'm using GWT now and I find it to be a vast improvement over perl/CGI/javascript which is how I prototyped a recent Ajax app. The perl version is fast and simple, to be sure, but I'm in a Java shop, so GWT is a better fit, and deploys nicely to Weblogic as well.

Re:A language that compiles to JS

[narcc]

OOP does not instantly mean "reusable" or "maintainable". The worst bad code I've ever had to deal with was bad OO code. Of course, most OO code is bad these days, and it's getting worse! (You haven't see spaghetti code until you've seen a medium sized OOP project!)

We had modularity, code reuse, and wrote maintainable code long before the OO hype.

Re:A language that compiles to JS

[wisnoskij]

If it is modular, reusable, and maintainable then it is OO and if it is not then it is not. It does not matter what the developers had never heard about OO or called the code OO.

Re:A language that compiles to JS

[narcc]

If it is modular, reusable, and maintainable then it is OO

Woah... Put down the kool-aid there pal. I've seen some wacky definitions of OO before, but this one takes the cake!

I recommend you go do some serious reading. You've got an awful lot to learn.

Re:A language that compiles to JS

[Necroman]

Dependency injection exists in GWT, see Google Gin, which is a subset of Google Guice. They also hava Google Guava (it's similar to Apache Commons) for GWT.

You are correct that none of the Java Reflection framework is there, but you can work around that most of the time. Google publishes a list of which classes of the JRE they emulate in GWT

Re:A language that compiles to JS

[wisnoskij]

So how do you create code that is modular and can be reused if the manipulators and data are spread all round your code instead of being grouped into a single spot (aka a object)?

Sure, all of the programming theoreticians might have long winded definitions for OO that I do not even really understand but go to a person or any college programming course and the definition is modularity, re-usability, and maintainability.

Modularity implies groupings of data and manipulator functions/methods into a class/object like system therefore it implies OO.

Re:A language that compiles to JS

[narcc]

So how do you create code that is modular and can be reused if the manipulators and data are spread all round your code instead of being grouped into a single spot (aka a object)?

Do you really need to ask this? Do you think that the state of programming was a convoluted mess before the object become in-vogue? I don't even know where to begin answering your question -- you seem to be missing too much to address in even a long discussion in this thread -- and you seem to have a bizarre set of assumptions about non-oo code. (BTW, you also seem to have "object" confused with "class".)

go to a person or any college programming course and the definition is modularity, re-usability, and maintainability.

No, it's not. Those are often cited as the benefits of OOP approaches, but none of those promises has turned out to be true. Moreover, OOP is not only not the only way to achieve those benefits -- OOP was supposed to achieve those benefits automatically. This turned out to be false. OOP does not guarantee modularity, code reuse, or maintainability -- Quite the opposite in fact. Improved developer productivity (what you should expect when those three pan-out) has not been found over procedural approaches in actual studies of the subject.

It's clear that you've been mislead. Don't worry too much about it, you're not alone. The hype and propaganda (by vendors of oo products) sold a lot of people on a myth.

Modularity implies groupings of data and manipulator functions/methods into a class/object like system therefore it implies OO.

No, it does not. A class is just one of many ways to achieve modularity. It's good sometimes, but not all the time or even most of the time. Again, you need know a bit more about the subject of modularity before we could begin a legitimate discussion of the various merits of class-based oo and other approaches.

Of course, I'm giving OOP too much credit here. The truth is that no one agrees on what OOP actually is Alan Kay (who coined the term) regrets it as so-called modern OO langauges are so far removed from his original vision as to be unrecognizable. Even two oft-claimed 'primary concepts' of OO, inheritance and encapsulation, are incompatible with one another! (Inheritance breaks encapsulation.)

I do use objects on occasion when they make sense to use. Of course, I use them extremely sparingly. I've found that it's not very often that an object is the best approach to modularity. Sometimes I'm forced to use them in place of (once common) structures like records due to the language I'm working in at the time, but that's a practical matter.

Google "OOP Criticism" for some insight here and google "Modular programming" to get a sense of what that is really all about, and why OO inheritance is directly at odds with the basic principles of modularity.

Re:A language that compiles to JS

[bradleyjg]

The aftermarket widgets are great, but the core translation engine, dev mode and RPC have (almost) no one working on it except google engineers - and there are many fewer of them today than there were two years ago.

That's a problem.

framework

[Anonymous Coward]

try playing with javascriptmvc

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

Re:Javascript: The good parts

[Anonymous Coward]

youtube seminaries? i dont think that word mens what ou think it means

Re:Javascript: The good parts

[davester666]

...filled with blank pages!

Re:Javascript: The good parts

[TwobyTwo]

I'll add another "second". It's a terrific little book. What the Elements of Style does for English, Doug does for Javascript. Yes, like many languages (certainly C++), JavaScript has a bunch of features that are poorly designed. Crockford shows a subset that's flexible and powerful.

What you don't want to do is try to make JavaScript into C/C++. They are different languages, optimized for different things. If you're going to program in a dynamic language like JavaScript or Ruby, don't spend all your time wishing it was static. The advantages are different, but if you're going to use JavaScript, use it in a style that exploits what it's good at. Crockford provides an excellent start.

For a more comprehensive reference, I like JavaScript: The Definitive Guide from O'Reilly.

Re:Javascript: The good parts

[shutdown -p now]

"JavaScript is Lisp in C's clothing."

... with syntax more retarded than C (what, you never thought it could be done? read the rules on implicit semicolons in JS!), and variable scoping rules more retarded than any language except for VB6, which uses the same rule. But at least VB6 didn't have closures, which cause you to step on that turd twice as often.

That this got standardized as the client-side language of the Web just goes to show that humanity is doomed. ~

Re:Javascript: The good parts

[Anonymous Coward]

There are also a couple of youtube seminaries with the author

So this author is really religious about JS, eh?

Re:Javascript: The good parts

[Anonymous Coward]

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's also a really thin book.

And also it has more pictures than text.
 
And also no code examples at all.
 
If you like railroad diagrams then you're gonna love it. Lots and lots of multidimentional railroad diagrams explaining BNF-like grammars of every aspect of the recommended style of coding without actually showing any code itself.
 
It may be a really thin book but it will give you hours after hours of great fun when you'll try to follow the diagrams in your head to actually imagine the code examples yourself. I even had dreams about railroad diagrams while reading this book, I kid you not. Great fun.

Re:Javascript: The good parts

[mangst]

Bump! I loved this book. I had a working understanding of Javascript when I started reading it (e.g. I knew how to create a function, how to create an "onclick" event handler for a button). By the time I finished it, I had a much deeper, more fundamental understanding of the language.

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

[Anonymous Coward]

As a C++ developer falling head-long into the javascript (and Flash... argh) world... this. This and THIS. Drink enough to the point where you can't distinguish the two and code away. The problems Submitter is having are ingrained in the language, you mostly just have to adapt.

Re:As a Javascript developer...

[confused one]

This. Drink enough that you can't think and don't care anymore. I prefer Jack Daniels to Scotch.

Re:As a Javascript developer...

[gnapster]

Should I aim for a 0.135% blood alcohol content, or will I need more when first starting out?

Re:As a Javascript developer...

[Anonymous Coward]

I can relate to this! In fact, I'm drinking Irish Whiskey right now, straight up! :-) I recently got a great job at a major company in a smallish division that does mobile browsers, and all of their webapps are JS and HTML5 based. My background is C/C++/PLSQL/Java/Dibol, etc. Our infrastructure is mostly Java, C++, and Javascript. Fortunately, I don't have to write a lot of JS code, and I don't have to write the JS webapps, just make them go as fast as possible - my job is performance engineering. In any case, I am reverse-engineering our code into UML models, and my head is about to explode! Hence, the Bushmills... :-)

As for Java, I still think it is C++ on training wheels. The fact that there is no multiple inheritance, except for interfaces, means that a lot of important classes are WAY overly big and complex, and do stuff they should not have to deal with, violating one of my major principals, locality of reference - keep the implementation close to the definition.

Re:As a Javascript developer...

[Assmasher]

Amen brother... And keep the Scotch cheap. No use wasting the good stuff - you'll be bathing in it before long.

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

[Mashiki]

I hear self-immolation works well too. And it does wonders at the end of the day when the boss comes up and wonders why your productivity is so low.

Re:As a Javascript developer...

[Anonymous Coward]

.1337%

Re:As a Javascript developer...

[Anonymous Coward]

Could you software guys stop with the hyperbole? You're sitting at a desk pounding away at a keyboard. Some people have real jobs that hurt.

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

[Lotana]

I am sure those people that have real and dangerous jobs also hyperbole and complain for the humour of it.

Give a mechanic/builder a cheap, chinese knock-off tools and force them to work with them and they will certanly react the same way.

You either laugh or you cry.

Re:As a Javascript developer...

[Anonymous Coward]

I don't know how -you- do it, but I have the equivalent of two or three shots of Bacardi 151, straight up, each night before bed - helps me fall asleep hard - and I never have a hang-over. Once in a great while, I'm not 100% sober when I wake up, but it wears off by the time I have to do any serious work.

Re:As a Javascript developer...

[shutdown -p now]

So it is - but on the web, it's JS or nothing.

My solution has been to stay away from web development for the time being. In five years or so, Dart or whatever will hopefully take over and inject some sanity.

Re:As a Javascript developer...

[shutdown -p now]

As for Java, I still think it is C++ on training wheels. The fact that there is no multiple inheritance, except for interfaces, means that a lot of important classes are WAY overly big and complex, and do stuff they should not have to deal with, violating one of my major principals, locality of reference - keep the implementation close to the definition.

Java 8 will have a nice addition in form of traits (they don't call them that, but that's what interfaces-with-defaulted-methods really are). This way you get multiple inheritance for behavior. Still no MI for data, but that is very rarely used in C++ itself, as well - while inheriting method bodies from several classes can be very useful.

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

Re:As a Javascript developer...

[shutdown -p now]

Some people have real jobs that hurt.

Writing books on JS, for example...

Re:As a Javascript developer...

[Anonymous Coward]

The Ballmer Peak varies for each programmer.

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.

Re:As a Javascript developer...

[Anonymous Coward]

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

I thought we established that reference counting is slower than garbage collection some decades ago. So I'd guess: everyone who wants their program to be fast.

Re:As a Javascript developer...

[shutdown -p now]

If you really hate that, you might as well just go header-only. There are some libraries that are actually written that way.

Re:As a Javascript developer...

[shutdown -p now]

I thought we established that reference counting is slower than garbage collection some decades ago.

Perhaps, but allocating objects inline on the stack (or inline within another object) is significantly faster than either. And C++ not only lets you do that, but encourages it - most objects in a well-written app are allocated that way. In contrast, in Java, everything is a reference - even when it logically shouldn't be - and then JIT ends up second-guessing whether something might be possible to put on the stack because a reference to it never escapes the scope (and it doesn't seem to be particularly good at it).

Re:As a Javascript developer...

[Anonymous Coward]

Yes, because comparing a situation where the mechanic can sustain physical injuries, lose a limb or life is JUST like have to learn to type an indecipherable sequence of characters at a desk... (eye roll)

Re:As a Javascript developer...

[gl4ss]

If you really hate that, you might as well just go header-only. There are some libraries that are actually written that way.

maybe I have at times gone that way hmmm?-)
doesn't mean that other people wouldn't bitch if they see that.

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.

Re:Not an Old-School Problem

[Anonymous Coward]

I was a mostly self-taught Delphi programmer with about 10 years under my belt (not much I'll admit) who learnt a bit of HTML in high school, when I started with PHP/MySQL+HTML4.01/5,CSS2.1/CSS3,JS using the book "MySQL and PHP for Dummies".

I'm now at a point where most of my questions are answered by either w3schools or php.net, but the the dummies book is a handy gentle intro. Also goes a little into setting up your server and security/hardening, which is as important as any feature of your app.

All languages have their pros and cons. I've never yet come across any reason not to learn a new one... even Visual Basic has its uses

Good luck

~ crutchy

Re:Not an Old-School Problem

[Oligonicella]

As someone who is "really old", in 1975, I was coding in TACL on the Tandem computer. I seem to recall one on the IBMs as well and I don't mean JCL, which was more scripting. Interesting Java stuff done on the Tandem too. Then there was that horrid MEES and MUMPS.

Re:Not an Old-School Problem

[Forever Wondering]

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.

I've been programming for 40 years. I was doing Basic circa 1972-1973, did tcsh/awk circa 1983-1991, discovered perl and used it ever since. I did write some JS code circa 1997. But, the JS was autogenerated by my perl 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.

Re:Dart?

[Anonymous Coward]

That's why he said PNaCl which is a machine-agnostic byte-code. Of course, by machine-agnostic they mean 32-bit little endian, but that should actually cover most architectures (all the ARM stuff is little-endian, x86 is little-endian & 32-bit mode is possible even on 64-bit machines since the PNaCl stuff implies AFAIK a separate process).

Re:Dart?

[shutdown -p now]

It would be interesting to see that message, since, from my own experience with LLVM, it's definitely very much suitable for a low-level virtual machine. If someone's using x86-specific instructions, why is that an LLVM issue it all? It's expressive enough to have the entirety of ISO C++ be compiled to it, what more do you want?

Re:Dart?

[BZ]

The message in question is http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

LLVM is only expressive enough to have C++ compiled to it if you use the parts of LLVM that are architecture-dependent. In particular, they depend on word sizes and endianness at the very least. You can't compile C++ to architecture-independent LLVM.

See http://news.ycombinator.com/item?id=2499763 for some links to the relevant LLVM documentation.

Now of course you can take any LLVM target you want and define a virtual machine for that target. Heck, you could define a virtual machine whose "bytecode" is x86 assembly. Whether such things are "suitable" or good for the web is a separate question entirely.

Re:Dart?

[crutchy]

nah i don't think it was a typo, unless there is such thing as a "consistent typo". maybe his "g", "h" and "t" keys are all glued together

Re:Dart?

[marcello_dl]

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

no, copy/paste. Just like js/php, in fact.

Re:Dart?

[julesh]

LLVM is only expressive enough to have C++ compiled to it if you use the parts of LLVM that are architecture-dependent. In particular, they depend on word sizes and endianness at the very least. You can't compile C++ to architecture-independent LLVM.

C++, by its very nature, depends on word sizes. This simple program cannot be implemented by a compiler that is word size agnostic:

int bytemasks[sizeof(int)];
int main(void) {
    for (int i = 0; i < sizeof(bytemasks); i++)
          bytemasks[i] = 0xFF<<(i*8);
}

The compiler must know how many bytes are in the words used by the architecture in order to know how much memory to allocate to the bytemasks array. This cannot be determined at runtime because the C++ specification requires bytemasks to have an exported address that is known at link time. Deferring the decision to the linker is too complex, as it could theoretically require the linker to evaluate arbitrary expressions.

In the end, the simple fact is that the complaints the author of the email you cite raises about LLVM are necessary, because it would be impossible to efficiently implement C-like languages without them. LLVM supports executing non-typesafe code, the same as C does. LLVM adapts the available integer and FP types to those supported by the target processor, the same as C does. By necessity this means there are platform-dependent variations in it.

What this does not mean (as you notice) is that it's impossible to use LLVM as a virtual machine. Go ahead and define your own virtual platform using it, with specified datatypes and endianness, and then use it to produce output code for a native platform (either ahead-of-time or just-in-time) that works with those types. It is simple to write LLVM plugins that modify data access to allow you to (for example) support big-endian ints on little-endian machines. All of this is entirely possible, and has been done. The only problem is that performance is ludicrously bad.

There are some solutions: you could write an LLVM analyser that detects which variables might be accessed outside of standard alignment (i.e., only those to which pointers are take and where those pointers are passed to code that might perform arithmetic on them using incorrect word lengths, or which feature in unions) and only performs endianness-correction on those. This would help a little, at least. For some programs it would help a lot.

Or you could use a type safety checker that ensures all pointers are only ever treated as pointers to the correct type, and no casts from one pointer type to a type with different size ever happen. This would restrict the class of programs you can run, but would allow you to ignore endianness as a constraint. Validated programs for your virtual platform could then be run directly on any processor supporting your chosen int/float sizes without modification.

You could simply ignore endianness as an issue. Pick one, and then let the VM->native compiler assume the native layout. Programs that perform inappropriate pointer conversions produce undefined behaviour. This wouldn't violate either the C or C++ spec, but is perhaps undesirable for a portable VM system.

Note that these three solutions to the problem are the only ones possible: anything else would involve violations of the C/C++ specs, and therefore the resulting VM wouldn't support those languages.

None of this solves the fundamental problem with doing this for the web, though, which is that LLVM doesn't provide sandboxed execution. It does not guarantee type safety (although type safety can be added on to it relatively easily, at least for some definitions of safety, again restricting the class of programs you can run) or memory safety (i.e. preventing accesses via freed pointers, local variables in expired stack frames, or out-of-bounds array accesses, which is a harder problem to solve), so it is impossible to guarantee that code running on it does not perform unauthorised actions.

Re:Dart?

[Anonymous Coward]

Ducks?

Re:Dart?

[BZ]

Agreed on all of the above. The upshot for PNaCl is:

1) Unreliable performance characteristics have to be traded off against not allowing all programs to run, as you note.
2) Sandboxing is a problem.
3) Actually getting it to run on a new architecture involves implementing the relevant LLVM virtual machine, not just writing the LLVM-to-native compiler you were probably writing anyway.

Re:Dart?

[Anonymous Coward]

nah i don't think it was a typo, unless there is such thing as a "consistent typo". maybe his "g", "h" and "t" keys are all glued together

that's why it would be "strongly" typoed....it enforces consistency in your typos. As opposed to those loosely typoed languages where you can use one typo here, a different typo here, and no typo (ie: the null typo) in other places.

I certainly like this explanation better than yours. I don't want to even think about why his g, h, and t keys might be stuck together.

Re:Dart?

[Anonymous Coward]

Same way you program with any other language... copy and paste from a forum.

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

[JoeMerchant]

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.

I might disagree with the productive part, while agreeing with the marketable part. If you can talk the talk, "oh yeah, I did this project where we pasted Javascript between Ajax and Ruby modules for X and Y all accessing a common SQL server and it scaled up to 20 parallel servers before the funding ran out..." that's what gets you hired - pointy haired boss thinks he needs somebody who can "leverage the existing Ruby codebase and deliver an SQL backend for the new client," so, you said Ruby and SQL in there and sounded convincing while you said it, you're hired.

As for productive, we had a little Python vs. C++ vs. Excel Macro code-off last year, Excel was the nominal winner because the existing data was in Excel and the destination of the processed data was also Excel, so it had a pretty strong homefield advantage, but the Macro code was really specifically purposed and very inflexible, to the point of pushing back on the requirements a little. C++ on Qt and Python on WxWidgets were more or less neck and neck for ease of coding and flexibility of product, Qt of course has access to more platforms and runs faster if you're doing something big, but in its place Python-Wx is just as good if you know how to use it.

If the project requirements had grown to about 3x the complexity (this was a one day programming exercise), I'd say the Excel Macro would have imploded and started to be a serious maintenance problem, Python and C++ would have scaled better, and at maybe 10-20x the complexity, the Python would have gotten a little creaky too, not so much due to inherent flaws in the language but more because of how it is typically used. Of course, you can write horrible C++ code too, but it has been around long enough that most experienced C++ programmers recognize the bad stuff in C++ on sight and can regale you with tales of projects gone wrong because it was done that way.

If your idea of productive is whipping off 3 or 4 relatively independent projects a week, leaning heavily on existing script libraries and not giving a damn if what you are doing is efficient or not, sure, JavaScript is fine, and it has the home field advantage in HTML5. If you're building bigger systems that evolve and need a maintenance lifetime of 5+ years, there are better tools for that.

Re:Adapt or die

[Threni]

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

Re:Adapt or die

[crutchy]

Re: "Adapt or die"

...sounds like a microsoft slogan

resistance is futile

Re:Adapt or die

[Anonymous Coward]

I read it more as "eat shit -- millions of flies can't be wrong!"

The obvious answer is

[AresTheImpaler]

Vodka, tequila, whiskey, sake, etc. choose your poison or mix them up for extra "tolerability"

Re:The obvious answer is

[Bodhammer]

I believe that is called a Long Island Ice Tea - affectionately known as a "panty dropper"!

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)

Re:one word: JQuery

[Leafheart]

If I may add an alternative word: MooTools.

I have used both extensively. On my former job we had a gigantic intranet application used in all of the branches across 10 countries. IT was a PHP\mysql with jQuery as a javascript framework. It worked great, the community is more developed so in some cases it is easier to find snippets. When I came to my current job I got a shock having to change to work with MooTools, which is what we use here. But after a while I realized that for serious heavy stuff it is a more robust framework. My current job is on a forums network with a couple of millions of daily hits and a half million userbase. Also, the extended frameworks for mootools, like Clientcide are really great.

Re:one word: JQuery

[Grishnakh]

This page seems to describe the differences between the two pretty well. In summary, MooTools and jQuery are trying to do different things.

Part of this consideration is the notion of a framework vs a toolkit. MooTools is a framework that attempts to implement JavaScript as it should be (according to MooTools' authors). The aim is to implement an API that feels like JavaScript and enhances everything; not just the DOM. jQuery is a toolkit that gives you an easy to use collection of methods in a self-contained system designed to make the DOM itself more pleasant. It just so happens that the DOM is where most people focus their effort when writing JavaScript, so in many cases, jQuery is all you need.

Most of the code you write when you write MooTools still feels like JavaScript. If you aren't interested in JavaScript as a language, then learning MooTools is going to feel like a chore. If you are interested in JavaScript and what makes it interesting, powerful, and expressive, then, personally, I think MooTools is the better choice.

Difficult to adapt to

[Kohath]

Adapt to it anyway. Do it by trying harder. The language isn't going to adapt to you.

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

[stevenfuzz]

I write PHP like Java or else I would have committed suicide years ago. I have showed PHP code at job interviews where they said "Wow, this actually reads a lot like Java, it's very clean". Sometimes I just don't get your particular viewpoint, not that I completely disagree with it. I honestly think some languages coding standards are awful (PHP), but the language is very useful.

Re:That's an antipattern

[Daniel Dvorkin]

This is fine advice for every programmer working in every programming language, and I really, really wish more people would follow it. I've noted that the people who say "it doesn't matter what language you use" are among the worst for trying to write code in every language that looks like it belongs in whatever language they learned first.

Re:That's an antipattern

[slimjim8094]

PHP is an exception (isn't it always?) :P

More seriously, I can't figure out if PHP actually has a coding standard, in which case it's obviously preferable to use something more readable than less. It always seemed less like it was thought out and more like it grew organically as people started using it for more than forms and counters and things. But my knowledge of PHP is limited to "it's a scripting language, embed it with <?php ... ?>, basic imperative syntax, here's the docs". Thankfully, I don't do anything with PHP more than hack on stuff for personal use sometimes. Can anyone enlighten me? What does quality PHP code look like? I'd guess frameworks like CodeIgniter or CakePHP would be the place to look.

Re:That's an antipattern

[nomel]

I don't understand this. 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, an object is an object with procedures, variables, scope, and all of whatever features the language supports, doesn't support, or pretends to support. Unless it's something like Haskell or a language that encourages unreadable lambda functions, they all look basically the same to me. Sure, javascript has interesting ways of declaring functions and building objects, but you could still translate it, basically on the fly and at a glance, to any other common language.

When I write code, in whatever language, it not that drastically different. It's all as clean and straightforward as possible for the task. If you look at it, you'll say "yeah, that's ", but only from syntax and slight formatting.

Maybe programming since I was 10 just means I don't see the code anymore.

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

[Beeftopia]

I have a background in C++. I could write PHP like a tentative teenager, write a line, see what it does, write another line, and soon have a working program serving web pages.

Or, I could apply classical code hygiene principles, define a few constants, limit my use of global variables, use objects with methods and properties, global functions,organize my code, think about what I want to do before I do it. There are many patterns one can implement in PHP. I recently implemented a singleton pattern because I wanted to call a query once, capture the data, instantiate the encapsulating object once, and be easily able to access that object's data through multiple other functions in the execution path without multiple database calls and multiple object instantiations.

You can be as tight or as sloppy with PHP as you wanna be. Not being strongly typed doesn't mean one is forced to write sloppy, buggy, opaque sh-t. I've seen the most abstruse, difficult-to-track down bugs in C++. Strongly typed doesn't automatically equal clean, solid, transparent code.

The quality of the end product is dependent, IMHO, on the code hygiene.

Re:That's an antipattern

[TheRealMindChild]

What does quality PHP code look like?

Just like everywhere else, it's subjective. REALLY *don't* use goto. I am serious.

Re:That's an antipattern

[Anonymous Brave Guy]

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, an object is an object with procedures, variables, scope, and all of whatever features the language supports, doesn't support, or pretends to support.

Well, no.

It's a popular claim that once you've learned a couple of languages, you can learn any new one in a week/a day/five minutes. And yes, some languages do share very similar underlying concepts with slightly different syntax. But that's far from a universal truth, and comparing C or C++ with JavaScript is an excellent counterexample.

To use a programming language effectively in the real world, you need more than just the syntax. You need to know how libraries work, including knowing your way around the standard ones and knowing where to find any major external sources like centralised repositories. You need the idioms to make best use of the features each individual language provides. You need to know the tools to create, distribute, and maintain your code.

If all you've ever programmed is "enterprise" stuff using C++, Java and C# from say 5 years ago, then sure, everything looks pretty similar: it's all basically imperative in style and mostly static, with a similar flavour of OO plus a few templates/generics; you follow a similar edit/compile/debug cycle and use similar tools to compile and distribute code; and the biggest conceptual jump is probably going from native code to running in a VM. Likewise, if all you've ever programmed is some trivial Perl, Python and PHP to write web site back-ends, one language is as scripty as another: almost everything is dynamic and can be hacked around at run-time; there's little emphasis on defining formal types; REPLs are common for experimentation; there is little boilerplate, so small applications can have very neat code but larger applications start to get awkward for the same reasons; there are many tools built-in for things like network and database integration; and so on.

Now try writing in C, assembler, Java, Python, OCaml, Haskell, Prolog and Lisp, and tell me with a straight face that they're all the same! And getting back to JavaScript, let's consider your own examples. A for-loop isn't the same concept in JavaScript as in C and C++ (until recently, at least, or unless you look from a very high level at what the C-style for loop is really doing). The object system in C++ works completely differently to the object system in JS. The features for manipulating functions in C and C++ are far less expressive than those in JS. Variables and scope work completely differently in JS, which in turn gives rise to some very important idioms that are unlike anything in C or C++. And of course the type system itself has a completely different flavour in JS from the C and C++ world, so your types and declarations do too. But apart from being wrong about every single example you gave, sure, JavaScript is just like C and C++. :-)

Maybe programming since I was 10 just means I don't see the code anymore.

Yes, you are surely very special and no-one else on Slashdot has been programming since they were a kid...!

Re:That's an antipattern

[Peaquod]

And getting back to JavaScript, let's consider your own examples. A for-loop isn't the same concept in JavaScript as in C and C++ (until recently, at least, or unless you look from a very high level at what the C-style for loop is really doing). The object system in C++ works completely differently to the object system in JS. The features for manipulating functions in C and C++ are far less expressive than those in JS. Variables and scope work completely differently in JS, which in turn gives rise to some very important idioms that are unlike anything in C or C++. And of course the type system itself has a completely different flavour in JS from the C and C++ world, so your types and declarations do too. But apart from being wrong about every single example you gave, sure, JavaScript is just like C and C++. :-)

Christ Almighty, don't be such a douche if you want people to appreciate your point. You just mocked the OP, who posted a valid - and I suspect common - point of view, while providing nothing but a laundry list of vague, unverifiable comparisons. I don't doubt you know what you're talking about, but dispose of the mocking tone and add some meat to your argument

Re:That's an antipattern

[eddy the lip]

I write PHP like Java or else I would have committed suicide years ago.

Oh, yeah. Me too. It seems like the PHP community is growing up a bit, too. I'm seeing a lot more cross-pollination from other languages, especially Java, when a few years ago there was almost a willfull ignorance when it came to good coding practice. The underlying language is still ugly as hell, but what's being done with it is getting better.

Re:That's an antipattern

[Anonymous Coward]

Can anyone enlighten me? What does quality PHP code look like?

Yes... like this:

Re:That's an antipattern

[Anonymous Coward]

Agreed. It's even in the ancient "How to program in C" joke. Item #5:
"Use macros and #defines to emulate Pascal."

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

[narcc]

REALLY *don't* use goto. I am serious.

Linus Torvalds would disagree with you.

What's funny about this meme is that you likely use goto all the time; it's just called 'break' or some other name or is in some other functional equivalent.

Re:That's an antipattern

[Anonymous Brave Guy]

Sorry, I wrote that post when it was late, and I guess what was meant as a bit of light-hearted ribbing doesn't translate well in a forum post.

To elaborate:

For-loops in C-family languages are built around control flow: you specify one or more control variables and explicitly test/update them on each go around a loop. This is very flexible, but in the common case that you just want to iterate over a sequence of values the for-each style loop used in many other languages, including JavaScript, is more explicit and usually much neater. You can translate between them to some extent, but only in the sense that for the C-style loop you can programmatically define the sequence you're iterating over on-the-fly while in for-each style you can simulate awkward combinations by generating the sequence ahead of time. Strictly spekaing, the C-style version is more powerful because it can also change the sequence on-the-fly while for-each loops typically lock the sequence down once they've started, though if you really have an algorithm that needs to do that then probably a for-each loop isn't the best tool to choose anyway. As a footnote, C++11 includes range-based for loops, so it can do something closer to the JS loop now as well.

Objects work very differently in JavaScript to how they work in C++ and similar languages. In JS, everything is very open and dynamic. You can add fields to and remove them from JS objects on-the-fly, where in C++ you have to specify exactly which members you want up-front as part of your class declaration and then any instance of that class is tied to those members forever. In C++ you would therefore use inheritance to model subtype relationships where you want to extend things, but in JS that kind of tool is unnecessary because if you want to extend an object's functionality you can just add to or modify the individual object. Where you do want some degree of sharing code between different objects, JS also offers a prototype mechanism, but it doesn't really have the concept that a given object is of some fixed type with fixed members at all.

Variables, scopes and functions work rather differently because JS doesn't use the block scoping that most languages, including those in the C family, do. Instead, scopes in JavaScript are primarily based on functions: define a variable in a function, and essentially it's visible anywhere in that function but not outside. Because JavaScript also supports (and frequently uses) functions defined inside other functions, which may be named or anonymous and may be called immediately or kept around as closures, this leads to a very different programming style when you want to implement things like modular design and data hiding. A good example is the popular JavaScript module pattern: I found some examples of the module pattern in this blog post. This also affects some fairly common operations like looping to add event handlers to multiple elements on a web page, where you'll often see each loop iteration "wrapped" in its own function that gets created, executed exactly once, and then forgotten, in order to avoid values used in earlier iterations being retrospectively updated by later ones so you're sharing more data between iterations than intended.

Re:That's an antipattern

[Terrasque]

This whole page seems a bit like deja vu. Had the same basic discussion just a few days ago, here.

I won't re-post most of it, but there is one link there that I think you might find interesting.. Python for Java people

If you look at the solution they first present there, that looks VERY java'y. If you scroll down to the "final" python version (honed by a lot of people commenting on it) it looks very different, at least from my viewpoint. The first code looks java'esque. The second looks pythonic.

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

Re:That's an antipattern

[Anonymous Coward]

Shouldn't that be

  if (stat(path, sb2) != 0)
            sb2 = false;

Re:That's an antipattern

[Anonymous Coward]

Found your bugs:

  else
    {
        if (stat(path, sb1) != 0)

should be:

  else
    {
        if (stat(path, sb2) != 0) // sb2!!!!

You've got the same cut and paste error below too!

    if (typeof sb1.st_dev != "undefined") // checking this twice instead of sb2!!!!!

Re:That's an antipattern

[multipartmixed]

LOL, thanks -- I love slashdot!

Guess I haven't got test coverage for that particular library routine yet!

Re:That's an antipattern

[TheRealMindChild]

We are talking PHP, not C or anything like it.

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

Re:Know the language, practice safe coding

[plopez]

I guess that makes sense.

Re:Know the language, practice safe coding

[Anonymous Coward]

You never want wierd things to happen. You want predictability, not some times works!

Can't teach an old dog how to sit...

[Anonymous Coward]

...so give up on it.

Douglas Crockford

[Anonymous Coward]

Try search about Douglas Crockford, he has amazing talks at yui theater and developed tools like jslint and a debugger one.

Re:Douglas Crockford

[sudden.zero]

Ok, now I see why my previous comment was removed. This guy is very good and he has a great book called JavaScript: The Good Parts. I highly recommend it!

Re:Douglas Crockford

[Johann Lau]

seconded!

http://yuiblog.com/crockford/

Re:Douglas Crockford

[Static]

Just be aware that he has some strong views on JavaScript and it's foibles which you may find you need to disagree with.

I passionately hate javascript

[Anonymous Coward]

I am also C++ guy and I really hate Javascript. It is not a language. It is a hack. Some programmer got drunk and designed it over the weekend just to make fun of his half-brained manager.
Javascript is a multiplatform piece of sh@#$.

Re:I passionately hate javascript

[larry bagina]

Yep. And now he's the CTO of Mozilla.

Re:I passionately hate javascript

[Anonymous Coward]

I am also C++ guy and I really hate Javascript. It is not a language. It is a hack. Some programmer got drunk and designed it over the weekend just to make fun of his half-brained manager.
Javascript is a multiplatform piece of sh@#$.

"I invented the term Object Oriented, and C++ isn't what I had in mind" ~ Alan Kay

Always funny hearing a C++ blowhard crowing about how hackish another language is. What do you suppose tacking Simula onto C was?

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?

[Anonymous Coward]

Right. Why study for a pay cut? Let's take one of the more complicated websites, Facebook. They likely have the best JavaScript guys using the best tools to make their interface what? Almost as good as desktop developers? Congrats on that guys. You've managed to make Logo render a scene from Tron.

Re:Why?

[Anonymous Coward]

Yeah but have you actually used their shitty APIs?

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.

Re:Why?

[Anonymous Coward]

I came here to say this. I'd upvote you if I could, but /. is still stuck with a hopelessly outdated moderation system.

Re:Why?

[Anonymous Coward]

Judging by your horrendous English language skills, I'd say you're correct to stick with languages that hold your hand! Stay in the shallow end and leave the lucrative jobs to the rest of us!

Re:Why?

[Anonymous Coward]

>Leave the crap languages to the script kids

Yawn. So either all these languages are designed by stupid people who don't have your incredible intelligence, and only used by silly kids, or you are redundant, with a redundant skill set, and a real nasty old man. You sound like your brain died some time ago.

Re:Why?

[Terrasque]

Facebook. They likely have the best JavaScript guys using the best tools

*almost dies laughing*

Phjeww, you haven't tried to use their api's or actually looked at their code, I take it?

Re:Why?

[Anonymous Coward]

And when you learn to use a proper test suite using a dynamically typed language, the quality of your products improve even when using a statically typed language.

Well..

[stevenfuzz]

I'm a c++ / Java guy that has worked with dhtml for around 10 years. The answer is both simple and complicated. For the most part, as you have realized, JS is a very dumbed down Java like language. It is about as strict as PHP (not as forgiving), and you can easily get going in the wrong direction trying to do seemingly simple things (like, getting the value of a select box). For the most part you can fake OO and more or less port over best practices from it's stricter big brother. I more often than not attempt to take the same approaches for JS as I would Java (albeit, it is not always possible or correct in the ways you are used to). Obviously you are not going to be setting up abstract classes or casting complex integers, but the pragmatics of programming are non-the-less the same. In fact, as a simple scripting mechanism over the dom, you shouldn't have to do any complicated data structure work (this is what the back end if for). So, the simple answer is to keep it simple, the complex answer is to attempt to follow best practices and use as little javascript as possible to achieve the desired effect. Just be glad you are not learning this 5-10 years ago, you would be spending half your time testing between browsers and the other half making your JS code look hideous.

Re:Well..

[Anonymous Coward]

JavaScript is noting like Java.

You dont "fake OO"... you using prototypical inheritance. Mixins anyone... Casting.. wtf?

If anything it is more like Perl. eg: native Regex, magic global variables, loose-typing, class-based or prototypical inheritance.

Seriously, you shouldn't even be commenting - what is with the "... use a little javascript as possible..."? Me thinks you have no idea.

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.

Re:should get you started...

[Anonymous Coward]

NO, MVC is not what you described.

HTML+CSS is the view. The model is your data (retrived thru db, web services, etc). JS plays a role in both the controller (as in getting, saving, validating, etc) as well as in handling the view (as in enabling/disabling/setting visibility, etc of ui components thru dom manipulation).

Re:should get you started...

[VoidEngineer]

Oh dear. That seems like quite a muddled way to view web development. But who am I to say? If you wish to use a confused metaphor, that's your prerogative. :shrug: From my own experience, the HTML/CSS/Javascript translation as Model/View/Controller works like a charm, and helps me keep everything very orderly and organized. Are you using HTML5?

Re:Drink

[Anonymous Coward]

My preference is vodka and lime...

Lime cancels out the harshness of the vodka, vodka cancels out the sourness of the lime, and the alcohol dulls the soul crushing pain of javascript.

Use good stuff for the first glass or two (grey goose is my preference).. then use the shitty stuff for the rest of the evening if you are cheap (polar ice is great for this!).

GWT

[Anonymous Coward]

Use GWT. It generates Javascript from Java.

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.

Re:GWT

[volkram]

I use GWT with Smart GWT (I think it was GWT EXT or something like that). The Smart GWT guys sell their enterprisey stuff too but I have had little trouble using Google RPC solution with SmartGWT. Recommend it.

CoreJS

[dubbayu_d_40]

It's an attempt to make Javascript more Java-like. To be honest, I've only scanned the docs and haven't used it yet, but plan to.

If anyone has some real-world experience they'd like to share, I'd love to hear about it.

http://echo.nextapp.com/site/corejs

Re:Open Source Code

[stevenfuzz]

The day I trust others to write code better than me is the day my work becomes just good enough. There is not a lot of vertical mobility writing good enough code.

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.

Groovy

[mark_osmd]

If you wanted to learn dynamic typing from Java, why not try Groovy

GWT for the win

[Anonymous Coward]

Write in Java, compile to JavaScript using GWT.

JavaScript "features" (weak typing, undeclared variables, ...) cause only bugs.

Lear perl

[TheInternetGuy]

My advice is;

Learn perl, learn to love perl.
After this any programming language will seem tolerable to you.

In fact, you may consider them as yet another of the many possible ways to do it.

Re:Lear perl

[Grishnakh]

I think there's real truth here. I learned Perl around 12-13 years ago, and I've never been really annoyed when messing around with any new language, even when I've tried some little web development projects with PHP, JavaScript/jQuery, etc., with one exception: CSS. I really hate CSS. Even with my C/C++ background, I can get good results quickly in JavaScript and especially PHP, but CSS is just a total frustration in trial-and-error with Firebug.

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.

Re:Try the Dojo Toolkit

[lytles]

i'll second this. and add that netbeans (and i'm sure other IDEs as well) is great with javascript, including libraries such as dojo. auto-completion, pops up javadoc-style comments, rudimentary refactoring, search for usages. once i got my mind wrapped around the closures and prototype-based inheritance it didn't feel that different than java. though the lack of strong typing is always going to be a limitation - no two ways about that

http://blog.nqzero.com/2009/08/dojo-api-code-assist-in-netbeans.html

Google has tools for you

[Anonymous Coward]

You can write in a type-ified version of javascript with a 'compiler' which statically checks your types and creates a minified javascript 'binary' for you to serve:

http://code.google.com/closure/compiler/
http://www.amazon.com/Closure-Definitive-Guide-Michael-Bolin/dp/1449381871

Or you can use GWT, and write java which compiles to javascript:

http://code.google.com/webtoolkit/

Or if you want to be on the cutting edge you can try DART, which is a whole new language, which compiles to javascript.

http://www.dartlang.org/

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.

Re:My tip

[Ryanrule]

This applies to dating as well.

Re:My tip

[DMUTPeregrine]

I have a similar bit of advice I give to people who ask me "what programming language should I learn?"
I tell them "Learn 3: one imperative, one object-oriented, and one functional. If you can do that you will be able to pick up the currently popular language more easily. Try C, Java, and Haskell. You'll be a better coder for it."

Re:My tip

[Anonymous Coward]

Obligatory XKCD:
http://xkcd.com/224/

Re:My tip

[Anonymous Coward]

How does lisp apply to dating? You're thexthy?

Don't bother

[Anonymous Coward]

There are many tool kits like jQuery which have zillions of plug-ins that already do most of the bread and butter functionality you'll ever need. There's little point in cutting javascript yourself for most things, not unless you're a professional in the language and need to.

Re:Don't bother

[Anonymous Coward]

True, besides you can't do anything proprietary in Javascript. For anyone that wants to do source code that matters, might as well not do something better done as an open source project.

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.

Firebug

[bob0the0mighty]

Firebug is a great tool for working with JS in all situations.

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

Re:Be dynamic when you use a dynamic language

[Anonymous Coward]

Ah, unit tests... twice the code, twice the time vs a statically typed language. I love getting paid by the hour... thanks web :-)

Re:Be dynamic when you use a dynamic language

[Anonymous Coward]

Um...you don't write unit tests in statically typed languages? And somebody pays you money to do that?

Re:Be dynamic when you use a dynamic language

[Anonymous Coward]

unit tests are just busy work for the newbs

Re:Be dynamic when you use a dynamic language

[steveha]

Ah, unit tests... twice the code, twice the time vs a statically typed language.

Wow, what a terrible attitude you have. You sound smug about it, too.

Learning to work in Python exposed me to the unit-tests way of doing things, and once I understood just how useful they are, I started doing them in my plain old C code as well.

Unit tests free your mind. You can completely re-write your core components, and if you have good unit tests and they pass, you don't need to fret over whether you have introduced some subtle bug that will bite you later.

For C and C++ developers, unit tests in combination with assert() can find all sorts of bugs for you.

I haven't done a scientific study, so I don't have any actual metrics for you, but I am completely convinced that the time I spent in making good unit tests has been repaid by the bugs the unit tests caught for me.

Right when you have written new code, and the code and its corner cases are fresh in your mind, you can easily whip out a few good unit tests that will make sure the code is good. It doesn't take anything near "twice the time". Then, when you run your unit tests, they never get bored and they always cover all your code. And they catch things.

And you might be a tough loner, slinging the code and never making mistakes, but what if you have to work with others who might not be as awesome as you are? "Before you commit your changes to the repository, make sure the unit tests all pass." And you have fewer problems.

I love seeing an assert() fire; that's one bug I didn't have to run down by hand in the debugger. Maybe you really love running the debugger? I'd rather leave work earlier.

steveha

Re:Be dynamic when you use a dynamic language

[Anonymous Coward]

If I wasn't an AC I'd mod you up to the limit.
Spot on!

Re:Be dynamic when you use a dynamic language

[r3x_mundi]

Unit tests are great...but don't fall into the trap thinking that if you cover your code with them, it will find all your bugs, or protect you from changes introducing new ones.

Unit tests are usually very granular and designed to test specific scenarios. It also forces your code to be very modular in order to isolate the things to test. These are not bad attributes, but what many programmers forget is an application is the sum of its parts, and things most often break in the integration of all those pieces...not just isolated individual pieces you wrote the unit tests for.

Unit tests are just one part of the toolkit. Other tools and practices are good too. Writing clean code, logging, peer review etc. Even with perfect unit tests, the debugger is still indispensable for actually tracing into the code when you find a problem and understanding whats going on.

Re:Be dynamic when you use a dynamic language

[steveha]

So now we have gone from "unit tests have no value and are just double the work LOL" to "unit tests don't solve every problem".

I agree: unit tests don't solve every problem. I said I'm happy every time an assert catches a bug; I didn't say I never use the debugger anymore.

things most often break in the integration of all those pieces...not just isolated individual pieces you wrote the unit tests for.

Don't you have unit tests that exercise the whole system? I do.

I work with audio, and I have unit tests that run reference files through the system and then verify that the output is close to what was expected. This is an end-to-end unit test, which will catch bugs in the I/O layer, bugs in the processing code, etc. etc.

Of course you'll never get 100% coverage. (Although SQLite claims 100% branch test coverage!)

steveha

Re:Be dynamic when you use a dynamic language

[r3x_mundi]

Sorry if i sounded critical, and thanks for the feedback.

Re:Be dynamic when you use a dynamic language

[Anonymous Coward]

You can completely re-write your core components, and if you have good unit tests and they pass, you don't need to fret over whether you have introduced some subtle bug that will bite you later.

Only for very rare applications. If you talking about most CRUD applications, if you really refactor/rewrite some class you must rewrite and some or all tests for this class. Big refactors completly break tests, and you need to write new tests. Where is safety in that? Thats why I better rely on Integration testing, with some corner case inputs.

JS is not OO

[bunhed]

Javascript is not perfect but more importantly, it's not OOP. Forget OOP, see it for what it actually is and it turns into a pretty decent little languange actually. If you are a C++/Java head that is hard to do but just the act of seeing code as prototypes, without the OO paradigm, is a worthy exercise. You gain a cool way to view problems and it changes the way you code OOP to boot. ++ imho.

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.

Re:JS is not OO

[Anonymous Coward]

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

For the record: Neither is C++. Ask Alan Key, the one who invented the term "Object Oriented".

Re:JS is not OO

[Lennie]

And functional like LISP.

Re:JS is not OO

[Anonymous Coward]

No, JS is not prototype-based. Claiming that JS is prototype-based is a clear indication of never having used a prototype-based language. In a prototype-based language, you create objects by cloning a prototype object. In JS, you create an empty object which (typically) uses some existing object as a fallback.

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

Re:Get Over Yourself

[gl4ss]

indeed it's easier to get brainwashed to kamikazing if you first forget everything.

(but yeah, if he's a generalist, he shouldn't put too much into already knowing language x before starting with js. just get hands dirty and start doing it..)

Re:Get Over Yourself

[Anonymous Coward]

:)

Re:Get Over Yourself

[bar-agent]

I know you didn't just say the JavaScript is Zen-like!

That's it, I'm gettin' mah gun.

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.

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.

Re:These steps broke the logjam for me

[Anonymous Coward]

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.

The latest edition of "Javascript: The Definitive Guide" is 1098 pages. Somehow, it looks even larger than that on the B&N shelf, maybe because of the way it's bound. And you look forward to reading as much as, let's say, a lawyer looks forward to catching up on the case law in some narrowly specialized area.

Meanwhile "Javascript: the Good Parts" by the same publisher, is 176 pages.

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:Go with the flow, my man

[WankersRevenge]

So in summation: Whoop, Whoop, Whoop, Nyuk, Nyuk, Nyuk

Yeah, that's my experience with JavaScript too.

(i kid, well written post, btw)

Go With The Flow or Vaadin

[Anonymous Coward]

If you *really* want to learn the screwball, loosey-goosey mess that is Javascript/HTML/CSS, then you just need to dive it and embrace the chaos. If you just want to be able to write web apps while leveraging your back-end Java skills, then check out frameworks like Vaadin.

Re:Open Source Code

[Beeftopia]

Javascript is a powerful complement to PHP, databases and server-based functionality. To do AJAX for example, you have to create the XMLHttpRequest object - created in Javacript in the browser - to send data to the server. And the browser is a very powerful engine. It should be exploited. It can pick up some of the server processing. I hear what you're saying about your code being totally exposed, but you can always keep the proprietary stuff on the server and send down the HTML only in those cases.

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.

Adapt and you might like it.

[Anonymous Coward]

I'm an old timer like you. I made the jump about 2 years ago and I have to admit the jump was difficult at first because I kept trying to fight it. What! You don't know until you run you script and it doesn't work that you have a typo? How weird. Once you get over this you realize, hey, this is kind of cool, I can go into a web browser and it tells me what is wrong, much more so than the c/c++ compiler ever did.

My recommendations:

use http://www.w3schools.com/ as your go to website for reference.
Get used to both Chrome's development tools as well as Firebug in Firefox. You debugger is your browser tools, not an ide.
Learn jQuery, even if you think you don't need it you WILL use it if you get seriously into javascript.
There are several patterns that simulate data encapsulation, google it and read about them.
Closure is your friend. It is a very weird concept but once you use it you can't live without it because it allows encapsulation.
If you are curious how something is done on a website, right click on it select "Inspect Element" in chrome or FF, go to the script tab and look at the source, this was weird to me, hey all your source is available to look at. If the source is minimized ie9 will even unminimize it for you.
Your ide is nothing more than a text editor, not better than vi, notepad, you pick, though eclipse/Netbeans/DevStudio all give you things like code completion.

After my 2 years of working with javascript, I can honestly say it is kind of fun and maybe even rewarding...Do I miss the tough technical problems from C/C++, of course but you know what javascript gives you a whole new set of problems (my favorite is tracking down things where an if statement doesn't work because it is comparing a string instead of a number and doesn't tell you, so 3 == 3 will return false).

GWT (Google Web Toolkit)

[Anonymous Coward]

GWT lets you write your front end in Java using widgets. It compiles your code to Javascript taking care of any variations needed to work on the different browsers.
You install the GWT plugin to your browser, and whamo, you can trace through your front end code in eclipse, without needing to redeploy changes to the server. Beautiful!
I replaced a JSF/Facelets/RichFaces/JavaScript/AJAX/HTML/XML/CSS implementation with GWT and saw a massive performance increase coupled with humongous decrease in complexity.
I honestly feel sorry for any poor sucker stuck in AJAX/JavaScript/CSS/HTML hell. Let Google take care of browser compatibility problems and get to use Java on both the front and back ends. What more do you want?

Re:GWT (Google Web Toolkit)

[volkram]

Agree 100%. Toss in SmartGWT, especially if you are doing business apps.

Old school != IDE

[Gothmolly]

If you're an "old school developer" you use vi, in a telnet window. You don't get 'help' from an IDE.

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.

Re:Here's an example

[oakgrove]

<

that's ampersand, l, t, then semicolon.

Re:Here's an example

[Anonymous Coward]

&
that's ampersand, a, m, p, then semicolon.

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.

jQuery

[Anonymous Coward]

jQuery is the answer to everything.

Re:jQuery

[Anonymous Coward]

jQuery is ONE answer, the answer to everything else is 42!

Re:I thank you for y0ur time

[Spiked_Three]

Yes, that is what Java script code looks like.

Stop Thinking About It

[zieroh]

I never really understood the objection to loosely-typed or untyped languages. I go back and forth between C/C++ and PHP and Javascript all the time, and it never even phased me.

The key to dealing with untyped languages is to focus not on what you have, but what you need. If you absolutely have to have an integer, not a string carrying a series of numbers, make it an integer and use it. If you need a string and a number won't do, make it a string. Stop focusing on the correctness of the typing and just focus on what you need at that particular point in the code.

By the same token, this is identical to the advice I give to beginning programmers struggling with C pointers. Stop focusing on Lvalue / Rvalue and just focus on what you have and what you need. If you have a pointer and you need the value, prefix with an asterisk. If you have a value and you need a pointer, put an ampersand in front of it. It's really that simple.

Keep the hell way from that shit!

[Anonymous Coward]

Javascript is a complete clusterfuck. Its dead zombie hand is dragging down the whole web.

Stay away! Keep to languages where it's actually possible to write good code.

Or get your brain removed and join the rest of the morons drowning the world in ever more stupid broken javascript code.

Have some fun with node.js

[radcore]

I am not sure if anyone on the thread has mentioned node.js (some folks here can probably explain this better than me) , but node.js is an incredible hybrid of a robust python-esque interpreter with the syntax of JavaScript. Node.js's primary use is for networked computing. However, If you want to practice learning JavaScript, it will be a lot of fun hacking within node.js since it allows you to do so much more stuff outside the browser.

JavaScrapped?

[Anonymous Coward]

Brendan Eich: Hey, I added a nifty new scripting language to Netscape!
Marc Andreessen: You mean you implemented Java natively in the browser?
Brendan Eich: No, That didn't work out. I had to scrap that idea.
Marc Andreessen: What, Java Scrapped?

use strict

[swsuehr]

The latest ECMAScript standard includes the 'use strict' pragma, which is one step towards what you're looking for.

Also, I was playing with Visual Studio 11 Express preview and it includes some decent code completion for JavaScript, which maybe fulfills some of your IDE stuff; though admittedly I haven't put it through its paces to see how well it does JavaScript code completion. Eclipse for JavaScript developers might do the same, I honestly haven't used it in a while for JavaScript writing. (I still prefer Vi for coding, versus an IDE, fyi).

Use the tools in Chrome or Firebug for Firefox to help with debugging.

You won't find the same advantages of compile-time error checking that you currently have but it also forces you to become more disciplined about thinking through your code and test cases when writing JavaScript. Obviously, the tradeoff is that if you don't test for it you won't find the error until someone finds it in the live environment.

Others have pointed out jQuery and I'll echo that. However, if you're like me you'll want to learn some of the underlying bits or the "why" something works and then augmenting with jQuery and other libraries. You'll want jQuery for most of the frontend work that you do.

And finally, I can't talk JavaScript without shamelessly plugging my book, JavaScript Step by Step.

Steve

Type system

[The Evil Atheist]

For me, the best practice I find is to have a demarcation between your code, and whatever language/libraries you are interfacing with. Understand the contracts of your own code and make sure nothing that passes through the border violates the contracts. That way, within your own code, you can assume certain type information will always hold true. I find it works whether the program's type system is formal or informal*.
* I prefer to use the formal/informal distinction for type systems instead of static/dynamic, because if you think about it, "static" and "dynamic" is actually about the implementation of the type system, whereas "formal" and "informal" tells you the class the rules of type conformance in a language are: whether something is spec'd out in advance (which is possible in static or dynamic languages), or if there is some delayed type comparison calculation (which is also possible in both static or dynamic languages).

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.

Re:Sure ... The first thing you should do is

[Anonymous Coward]

This.

I've noticed all of the developers who go around bashing languages, claiming their inferiority, etc, are generally insecure and deficient themselves. A true computer scientist doesn't blame the tools. Be adaptable. Don't shoehorn every paradigm into what you're used to.

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.

[Anonymous Coward]

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 kinda thinking barely flies in the traditional software community.. forget about the web!

And I'd say ultimately you can learn to "efficiently use" something while still maintaining the opinion that it's a piece of crap. Javascript and PHP for instance. You can learn to work around the various issues, and learn which bits are ok and which should be avoided (I find it funny that as someone else pointed out, the most recommended book for javascript is a book that primarily does just that) .. but that doesn't make the language any less ugly.

Re:You have a clear anti-JS bias.

[bradleyjg]

Right, a language with a function named mysql_real_escape_string() is just different. As is a language with occassionally significant whitespace.

Perhaps the word you were looking for is 'special'?

Re:You have a clear anti-JS bias.

[shutdown -p now]

As in "special olympics"?

Re:You have a clear anti-JS bias.

[Anonymous Coward]

The value of a language is what you can do with it. Javascript runs in a browser, which is why people use it.

Software developers need to cope with the world the way that it is, not the way that they would like it to be. For my money,
java is a nice enough language, but it is rather heavy and verbose in use. Javascript, on the other hand is quick and easy to
use simply. It's a lot less prescriptive than Java, so you can write in many different styles. This is both a good thing and
a bad thing.

Life, and programming, is about compromise. Java's compromises are at a different place from Javascript. For my money, a
good programmer should be able to cope with a rigid language like Java, but also with a looser one like Javascript. The OP
clearly agrees or he wouldn't be asking.

For my money, the main useful information that the OP can take away is nothing to do with the language per se, but the libraries.
In Java, a lot of core functionality is offered by the standard API. It is the reliability and availability of this API which, to me, is
Java's core strength. Javascript doesn't have this. The core language is not enough to do more than get you going. The bottom
line with JS is that you probably need to learn a framework (jQuery or equivalent) if you want to get going.

Phil

Re:You have a clear anti-JS bias.

[elp]

And someone competent in using the language would know enough to use the db independent function calls and that once you start escaping strings you are doing it wrong. Much like a competent c programmer understands the specific limitations of strcpy.

All the very well paid professional python programmers I know seem happy using a language with significant whitespace.

Re:You have a clear anti-JS bias.

[Anonymous Coward]

Comparing JS to PHP is just cruel (to JS, for those wondering). PHP is effectively broken beyond repair. You can write good code in PHP, like in any language, but it's always going to have issues. JS, on the other hand, is not broken. It has some bad features, but you can just not use them. The stuff that's good about JS is really good.

As somebody who writes a lot of code in both JS and Java, I'm sometimes annoyed by JS because it's too lax about some stuff, but I'm more often annoyed by Java, because there are things I just can't do there.

Re:You have a clear anti-JS bias.

[Joce640k]

Sorry ... but weakly typed languages are the junk food of the programming world.

e.g. All those SQL injection attacks? Mostly down to weak typing.

Articles like this (which is highly regarded in the weak-typing world)? Wrong, wrong, WRONG. Don't rely on writing code to try and make errors stand out if people pay attention, write code that refuses to compile if you make a mistake.

Compile-time checking is one of the foundations of writing solid software. The compiler never forgets to check stuff, it never has a bad day, a late night or insufficient caffeine. The more work you can get it to do for you, the better.

(This rant also applies to C programmers - C hardly lets you automate anything, get C++ and start using proper containers/strings ASAP)

Re:You have a clear anti-JS bias.

[Joce640k]

How about a language that refuses to even compile if you don't pass objects of type 'escaped_string' to the SQL functions?

Or ... how about defining a constructor for escaped_string to make the the whole thing transparent. The compiler will convert all unsafe_strings to safe_strings automatically if you try to pass them to SQL functions. And it never misses one. Ever.

Put the burden on the compiler, not the humans.

Re:You have a clear anti-JS bias.

[Anonymous Coward]

Two characters to access object attributes because the period was used for concatination before OO was tacked on? Yuk.

http://programmers.stackexchange.com/questions/32541/why-are-php-function-signatures-so-inconsistent

Yeah, PHP has legitimate things wrong with it - enough that it's perfectly reasonable to avoid it like the plague.

Re:You have a clear anti-JS bias.

[Anonymous Coward]

Man, I LOVE these flamewars about programming languages.
The day there is peace on this topic, that day is the end of SlashDot.

P.S.: JavaScript sucks, PHP sucks, Java sucks, shit, even Python sucks. C and C++ are the only true programming languages. End of story.

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:You have a clear anti-JS bias.

[Anonymous Coward]

Oh, barf.

Re:You have a clear anti-JS bias.

[Anonymous Coward]

C++ sucks too. C is alright.

Re:You have a clear anti-JS bias.

[Anonymous Coward]

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.

Shocking, I know, but different can still mean inferior. As is the case here, Javascript is absolutley inferior to most other commonly used languages. Simple things are frequently painful in comparison.

The problem here is, you're in denial about being a fanboy. Languages have pros and cons. Developers tend to pick languages which best support their target while exposing the least number of cons. Sadly, with web development, the choices are rather limited. And so developers are forced to use, more or less, one of two languages, whereby Javascript is the most prevellent one. But none of that changes the fact that Javascript is a second rate language, which most would be happy to never code in, if only the language were not forced upon them.

As for your PHP comment, the fact remains, PHP sucks horribly. Made worse is the fact that many very inexperienced developers pick it up and create very buggy and very insecure libraries which then become adopted by many other unexperienced developers. Just because you're a fanboy and refuse to acknowledge that we don't like in a perfect world, doesn't mean that the lion share of hate against PHP is unjustified. In fact, the bulk of the gate against PHP is not only justified, but re-enforced daily when one is forced to suffer through using it.

Honestly, you need to listen to those around you who clearly know what they are talking about. Being in denail isn't helpful for anyone. And it certainly doesn't lend credibility to you.

Re:You have a clear anti-JS bias.

[Joce640k]

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?

Seems a bit draconian to me. Probably non-portable, too.

Re:You have a clear anti-JS bias.

[Anonymous Coward]

Reliability: Does not come from Static/Strongly typed languages (injection attacks, null pointers, instanceof checks due to bad generics, etc. rebuke this)
Performance: Learn when you allocate/dereference pointers in your language, dependency injection due to generics is not going to win if you have to do multiple pointer lookups vs 1.
Maintainability: Tooling, Static/Strongly typed are winning this battle, but things like Cloud9 and Aptana are forging ahead. Debuggers / Profilers exist for any decent embeddable JS engine (except Chakra).
Correctness: Testing, if you are not testing for cause and effect and instead are testing if your language constructs are acting the same as it should without a real like cause and desired effect (along with points to check as it handles the cause), you are doing it wrong.
Portability: JS wins, do you have a device that cannot run JS? If so you are doing embedded work that wont be portable anyway. Try the good ole DLL passing game in windows if you want to see something that is not portable. Java is portable enough, but the JVM is not always on a machine, a browser almost always is.
Quality: C++/Java have compiler linting via static types... JSLint/JSHint can do this with a build script in JS. Anyway, I have seen terrible code, code that has nested for loops to do a single array iteration in Java/C++ how is quality being measured here?

Re:You have a clear anti-JS bias.

[Alex Belits]

Probably non-portable, too.

All servers support that. Not all developers know though.

Re:You have a clear anti-JS bias.

[bradleyjg]

There is an argument (a bad one, but an argument) to be made for significant white space. There is no possible rationale for javascripts' usually-insignificant-but-occasionally-very-significant white space gotcha.

Re:You have a clear anti-JS bias.

[Anonymous Coward]

No, he's just a guy showing clear bias for one language, for reasons which are irrelevant in the context of the other language. It's like a family guy lambasting a single guy for not getting a large family car, even though the single guy has no need for such a car.

Use a framework like Dojo

[Anonymous Coward]

While it doesn't have the prettiest of built in widgets, the real power of Dojo is as a framework, namely the widget framework. It get's you thinking of your javascript as components and adds a certain sense of object oriented-ness to javascript. Additionally, a framework like dojo will offer various functions for common operations (like cloning nodes, dynamically adding to the DOM) easier by abstracting out the cross-browser complexities. As a server side Java developer a toolkit like Dojo has actually made me look forward and enjoy writing Javascript.

There is a Google solution for that...

[Anonymous Coward]

It's called Google Web Toolkit.

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

Um. Programming is hard.

[fahrbot-bot]

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.

I'll probably get nailed for this but... Sorry, unless you're re a slack programmer who needs the language and editor to make up for your lack of discipline, you should be able to program well regardless. You profess to be an experienced C programmer, but complain about weak typing and the need for lots of compile-time checking and help from the IDE. What C compiler have you been using? I'm sure people can write novels about the crap you can get away with in C. Back in college (1980s), the K&R C compiler on the BSD/VAX system let me cast on the left of the equals sign. As for compile-time error-checking and IDE, I used (and still use) Emacs. Stop your whining and start using your brain.

similar situation , use jquery

[RockGrumbler]

I have a similar background. More Java then c however. The one thing that makes JavaScript semi readable and maintainable across people and time, is a good framework like jQuery.

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

[WillKemp]

[......] I try to keep myself from becoming entrenched in any particular mode of thinking... it leads to inflexibly dictating that all else is inferior.

That's the best way to approach all of life. Sadly, there are a lot of people who don't think like that - and there seems to be plenty of them around here!

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

[Anonymous Coward]

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

Wrong, both of you. Yes, they are different, and as a result of those differences one or the other may be superior/inferior to the other from certain specific points of view .

Use the right tool for the job, some work better for some things and some don't. Deal with it.

That being said, the submitter's problem has nothing to do with the languages. The problem is he has gotten used to writing sloppy code and having the compiler catch his mistakes and tell him what to fix. Either slow down and tighten things up, or else hire an intern or assistant to review your code before hand.

Compilers shouldn't be catching major blunders, just simply typos, and quite frankly your IDE ought to be able to do this for you. While the scripting languages do not force strong types, that does not mean that the code cannot be written with strong-type principles in place.

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

[Anonymous Coward]

tools vary in their design not just to accomplish different things with different materials, but also to allow people of various levels of skill to have fun with the art (and make a living?). I've seen crude pieces of sharpened metal in a master craftsman's work shop while I myself, with little experience, can enjoy making usable furniture simply because of electronic tools that make the job easier.

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

[Anonymous Coward]

Actually -- if you're referring to an "all js" sort of stack -- say chrome as the client, and node.js as the server -- then it's all c/c++.

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

[Anonymous Coward]

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

It just might not be called a web site but a java applet, or even a silverlight or a flash application.

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

[Anonymous Coward]

And how would you run your JS program, without the Web Browser or the interpreter that is written in C/C++ etc?

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

[snowgirl]

Wrong, both of you. Yes, they are different, and as a result of those differences one or the other may be superior/inferior to the other from certain specific points of view .

Use the right tool for the job, some work better for some things and some don't. Deal with it.

Indeed... you've said a little bit better what I was hoping to say. Thank you.

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

[justforgetme]

You are missing the point. People like you are, in other circumstances, called "The guy with a hammer seeing only nails".

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

[justforgetme]

Truly valid. My point (apparently to obfuscated judging from the replies) is that when you have a problem that has as it's widely accepted solution one language you solve it with that language.

The W3C is after all a democratic organization. If there is merit in, say, chromium's naCl the W3C will make room for it in the specs (and in some years we will have widely supported native code execution "happy compiling for 2^8 archs by then"). I don't say just live with it, seriously, if there is a good reason for having another format of code execution in browsers it should and will be included but because those mechanisms take too much time compared to one project's production cycle complaining is plain pointless. Better gather your resolve and put forth a civilized reform.

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

[justforgetme]

Dear AC:
  Those things are nothing like a web site.

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

[justforgetme]

Sure, now the only task you have to do is convince the 78% of Internet users to switch browser. :-)

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

[justforgetme]

Sorry, I meant www users.

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

[justforgetme]

Given a DOM binding and a function for generating asynchronous HTTP requests

yes...

The proposition was not meant to be an analytical hypothesis. I understand what you mean from that point on but (if I understand correctly) that would need you to also distribute a browser or browser plugin or executable to actually make available the site to an end user.

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

[shutdown -p now]

Yes, I concur with that. If you're a web developer, the best course of action today is to learn JS - and, what more, learn idiomatic JS, such that you speak the same language as other developers in this niche, rather than trying to do the equivalent of "#define begin {". Doesn't mean you have to like it - just know how to use it well.

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

[justforgetme]

Yes.
Yes.
Yes.

The thing is, you have to be able to make a good point with your proposition in order for a web standard to be expanded to your liking. Sure running compiled binaries in a browser would work wonders as far as performance goes. The problems I see with this are not performance or availablility. The www is created with openness in mind. that is one of the reasons an interpreted language was used for the client side programming. Running plugins and compiled code clientside is a philosophical nono as far as the w3c is concerned and they have their points. still the need for alternatives is apparent. the ewb grows in importance daily and if it remains js exclusive computing in general will end up a monoculture (as far as the web frontend is concerned).

Still the answer is not complaining but hacking. Dont sit just around bitching how awful js is. Get your hands dirty and provide an implementation of firefox that has a cobol/haskell/scheme dom interface, create cool apps that work only on it and when it gets traction it will become standardized.

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

[TheRaven64]

My point is that all of the advantages of JavaScript in the example come from things that are not part of JavaScript. DOM and XMLHttpRequest are APIs that are not part of JavaScript, they are external to the language. The advantages of JavaScript are all things that are not related to the language.

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

[Anonymous Coward]

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.

If you're not a web developer, you have ignorance as an excuse. If you are, please hand in your badge on your way out.

The solution you indicated is ass backwards. What the Web is currently working towards is:
(1) Implementing a standard widget toolkit supported by all browsers without the need for third party libraries;
(2) Allowing that toolkit full integration and extensibility with JavaScript and DOM;
(3) Implementing alternative language engines in browsers and making JavaScript just one language among several.

These measures, alongside the set of technologies dubbed "HTML5", the advent of unified semantic marking (schema.org) and a couple of other technologies (such as push notifications) make a good solution. Not falling back to desktop technologies.

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

[wallsg]

by Alex Belits (*******437*******)

Impressive!

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

[Anonymous Coward]

Browsers (currently) do not run Java directly in them, so you can't compare those "programs".

*if* browsers were able to run Java directly in them, then I think you'd find that the resultant webpages far more "stable" as the strict type syntax would eliminate most (if not all) type conversion errors and "X not member of Y" errors.

That being said ... I really like JS. I program in Java for a living, but that doesn't stop me from liking JS in all its unsafe-typiness glory :)

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

[Alex Belits]

And they all require Javascript as the only supported scripting language (one you use to actually DO something on the client), all the ugliness carefully preserved.

I recognize that this is a significant progress compared to previous HTML/CSS/Javascript combinations. However that's only because previous HTML standards and Javascript are so awful. It may use little of Javascript when UI is tolerant to high-latency requests to the server, but there is no way to escape that language completely.

Integer arithmetic warning

[jlbprof]

My latest endeavor with JS made me very upset. JS does not do integer arithmetic well. Example to do a proper integer addition that is reliable I have to do the following: a + b | 0 or it could end up with decimal values. It wasted several hour of my time to find that one out.

Re:Integer arithmetic warning

[hcs_$reboot]

The problem is that JS does not have a "concatenation" operator and variables are not strongly typed ; JS may operate with strings when you expect an arithmetic operation (for instance a user input field contains the string "45", and JS considers it to be a string until it is converted to a number, using | or '- 0' for instance).
Perl and PHP use '.' as the concatenation operator, having less ambiguous operations.

Start here

[foniksonik]

Start here

http://addyosmani.com/blog/short-musings-on-javascript-mv-tech-stacks/

Then go here

http://dailyjs.com/2010/02/18/framework/

And continue reading

http://dailyjs.com/tags.html#lmaf

Then read up on AMD and CommonJS along with RequireJS and Node (server side JS).

You will want to understand JSON intimately.

You can't avoid Jquery but its no longer essential with Underscore and Backbone libraries.

Dojo and ExtJs are also interesting.

There is a History of JavaScript series on DailyJS as well that will prove useful.

Good luck.

gwt can help

[Anonymous Coward]

the gwt compiler compiles java into javascript.

No mention of GWT?

[nbender]

Work in Eclipse? Compile to JavaScript? Deploy wherever?

Oh the humanity....

perl gives power, javascript does not

[Anonymous Coward]

As someone whom has spent several months with perl, and some time with javascript, perl provides large amount of power/terseness, if you can handle the complexity of the entire perl language, which is VERY challenging to do.

As for javascript, it does not offer the power of perl, and it is still unfriendly. I do not like javascript.

Re:perl gives power, javascript does not

[TheInternetGuy]

As someone whom has spent several months with perl,

Tssk. You do not learn perl, or at least, you do not learn to love perl in several months, Not until you prefer to solve algebra using perl regexps have you truly learned to love perl.

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.

Learn Key Concepts and Find the Best Toolsy

[voridor]

I used to do a lot of Perl development but now-a-days I am doing heavy JavaScript work. My advice for someone starting out is that, initially, avoid libraries like jQuery until you get a good understanding of core JavaScript functionality. As a for instance, learn about how JavaScript prototype inheritance works (not the Prototype library, but the property). Also learn about closures as they are very powerful when used correctly. The following is a good article about the inheritance in JavaScript:

http://phrogz.net/js/c lasses/OOPinJS2.html

Chrome, Firefox, and even IE8/IE9 now have a JavaScript console that you can log to, this makes debugging worlds easier than it used to be back in the old days. Also, Firebug in Firefox and the built in debugging tools in Chrome/Safari/Webkit are very nice debugging tools that can be used to easily step through code and see what is going on.

Once you get used to debugging and some of the advanced features of JavaScript, then I would recommend starting to get familiar with a library such as jQuery or Dojo. If you know what the core of JavaScript does well, then you will know when to leverage a library method or a native method (because sometimes doing things the native way is faster). If you start doing jQuery, I would suggest reading an article about how to write it cleanly. jQuery is a nice library, but in the wrong hands can make for some very ugly code.

I used to really dislike JavaScript, but now that I have gotten to know the language well, it really is a nice little scripting language. I sometimes feel it gets a bad wrap.

GWT

[lkcl]

you want google web toolkit. it will allow you to stay in the shit world of single-inheritance java that you are used to dealing with, as well as give you a decent widget toolkit to work with. when you wake up from the insanity of fighting with java, and are happy to program in a decent compact language like python, there's always pyjamas. the advantage of taking this route is that the widget set API of pyjamas is near-identical to that of GWT 1.5, with bits of 1.6 and 1.7 thrown in.

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:B0rked closures is enough for JS loving?

[John Courtland]

Javascript is plenty retarded but Java does not have better closures. You can NOT close over free variables in a Java program.

Unit tests are your friends

[Anonymous Coward]

As a C++ guy who moved to Python, the best advice I can give is: Unit tests are your type checker, compiler, and then some. You will thank me later when you decide to refactor a large code base.

Writing any code more than 1000 lines in a dynamically typed language, without tests, is pretty much shooting yourself in the foot.

Finally, fall back to your common CS abstractions. The data structures are the same (lists, maps, structs, etc). It's still imperative code for the most part. The only thing to really 'learn' is the code-is-data mindset.

JS.Class - If you've ever used Collections...

[HellYeahAutomaton]

http://jsclass.jcoglan.com/

going down in flames

[greywire]

somebody beat me to the perfect opening line, but I'll use it again anyway..

I'll probably get flamed for this, but, don't even try!

That is, don't look at it as a transition. They are not used for the same things. Javascript is interesting yes from the perspective of just learning something different from what you are used to. I personally love learning new languages even if I don't ever use them.

I would recommend you play around with it, check out some of the libraries like jQuery or Prototype which make Javascript much more fun. But don't think you're going to transition away from Java any time soon, or at all. My recommendation? As a web guy originally (well, C and Assembly really, but web professionally) who's moving towards Java, I would say look into mobile app development on android. I have quite more enjoyed Java and Android dev than I ever did Javascript. But maybe I'm just too nostalgic for my Amiga C programming days..

Well...

[Anonymous Coward]

JQuery and a REPL.

Unit Tests are now your Compiler

[poor_boi]

One of the things you really miss with JavaScript is a compiler. Something to check your entire program for obvious errors. That's where unit tests come in. If you have Significant unit test coverage, you can run your unit tests instead of running your compiler. Unit tests nearly double in value (IMO) when used with a dynamic language that has no compiler.

Write your web apps in C++

[jrbrtsn]

using the Wt C++ Web Toolkit.

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 }

Re:It's a good time to look, but I wouldn't jump i

[Ryanrule]

I HATE ExtJS. Yet another chance for some fail offshort dev to put together something that works, but terribly.

That's really your problem with javascript?

[Anonymous Coward]

The dynamic typing is what bothers you? I mean, I would have complained about the DOM, or the fucked up object model, or the fact that there's no good way to debug it, or the fact that you have to write 4 different versions of your program just to cover the major browsers even when you're fully taking advantage of things like jquery that are supposed to be browser-agnostic..

Unit Test Framework

[hoppo]

Since it is weakly typed, Javascript can be very difficult to debug, in areas deep in your code. You can ease your transition by writing unit tests for all your Javascript code. Get comfortable with a Javascript unit testing framework, and write tests first. Then, when you are debugging problems in your tests, you will be training yourself to recognize the common problems that occur in Javascript code.

2nd

[bussdriver]

I'll agree with the parent; although, I've not read that book. Generally a book written for somebody of a particular background more useful.

Similar background for me (but 15 years ago;) although, if you have discipline and comment your code the typing issues are not a problem. I'm spoiled now; I like prefer javascript (if it only had named parameters...) If you like inheritance you will not be so happy and the performance loss from overusing the prototype system. If you are doing some major work that requires accessibility you can't. In some ways javascript reminds me more of Perl...

I recommend NOT using jQuery or most libraries. If you are just looking to expand don't attach yourself to a library that may fall out of favor when you need to do serious work later (and something else is popular.) Most these libraries are ways to hack pathetic browsers like IE6 which replace the API with different one - meaning you are not learning the standards. Not to mention javascript is used outside the browser. You can find a document.getElementBySelector() library out there and use that until DOM3 finally adds that officially (why it didn't make it to DOM2 I'd like to know!)
No need to learn browser related hacks; unless you have to deal with the problem today; in which case a library of hacks may be useful, possibly just for finding the 1 hack you need in the source code.

Douglas Crockford is amazing

[LS]

This man has done more for my understanding of JavaScript than anyone else. My abilities took a huge leap after reading his clear and deep explanations that get to the heart of JavaScript's design:

Douglas Crockford's JavaScript articles

He covers prototypical inheritence, classical inheritence, how to create private members, closures, engine performance, and other widely misunderstood aspects of javascript. HIGHLY recommended.

LS

Re:Douglas Crockford is amazing

[rock_climbing_guy]

I strongly suggest that you start with "The World's Most Misunderstood Programming Language: http://javascript.crockford.com/javascript.html. And then, watch his YUI videos.

Thanks for something real!

[SuperKendall]

I clicked on this story thinking "this should be great, I'll get to see the state of the art in Javascript IDE support".

Imagine my horror when I had to wade through pages and pages of language war, before I found your educational post. I'm downloading Aptana to check out now, thanks.

P.S. for those wondering there is a Mac version. The main screenshot looks awfully "Windows" so I wasn't sure they supported the Mac.

Also the hint on reading up on Lisp is very good. I've been doing JavaScript off and on for some time, just looking for a better IDE...

Re:Thanks for something real!

[narcc]

P.S. for those wondering there is a Mac version. The main screenshot looks awfully "Windows" so I wasn't sure they supported the Mac.

Surprisingly, there is a version for OSX. There is a Linux version as well.

As for this post being particularly "educational" I beg to differ. The functional programming advise is sound, but overkill for just about anything you'll acutally use JS for. Recommending jQuery is a huge mistake. The only reason to learn jQuery is to understand other peoples brain-damaged code that uses jQuery.

Aptana? I've never used it nor do I know anything about it save that there is a version for OSX, which I discovered in seconds with a two-word google search.

Re:Thanks for something real!

[VoidEngineer]

Also, probably too late for this overall conversation, but in case you're interested, it just occurred to me where the strongly typed data types are in the HTML5/Javascript paradigm... in the HTML5! There are specific data-type and data-role attributes you can give to tags in HTML5. So, if you need strongly typed variables in you web application, all you would need to do is write a single javascript function, probably using jquery selectors, to locate the 'data-type' and 'data-role' elements in the HTML5 tag, and perform whatever type checking you want. Then you just reuse that javascript function in all of your event code and callback code.

Javascript is NOT THAT DIFFICULT.

[Anonymous Coward]

I've been coding for 25+ years. I've coded in many languages from assembly to java to C#, etc, but HTML and Javascript are my bread and butter. I've been coding Javascript for 15 years. It is the best (really the only) language for running code inside a web browser, and web browsers are ubiquitous - and that is a good thing when trying to get people to run your software. It's a good thing to learn, and you should feel good about your decision to learn it.

Here are some tips I can give you from my 15 years of experince with Javascript.

First, about static / dynamic typed variables. I've never really had a bug in maybe 14 out of 15 years of coding Javascript that was caused by a problem with the wrong variable type. That isn't to say that I'm not sometimes being dumb when concatenating a few things together, but I wouldn't really call it a bug - it's part of programming any language. You might expect a compiler to throw an error if you have the wrong type, and it will when the code runs - which is every time you refresh your browser if you are executing the code you are writing. You should be refreshing and testing the code OFTEN while writing it, in some environments you could have the browser refresh and run the new code every time you hit save if you like. I sometimes code directly inside the browser and run code as often as I like, if there's a problem it's very easy to find and fix.

But, your variables aren't likely to spontaneously switch to a type you can't deal with in your code. It just never happens that I expect a number and get a string, especially when I'm coding algorithms that don't rely on dynamic typing or concatenating strings and numbers, which is practically 100% likely when coding algorithms. If you are writing encryption code or something complex that uses a lot of math, you won't run into a problem with dynamic typing. You just will not. If you do then you really should reevaluate your coding standards. Because it just doesn't happen. Ever. There are some cases to be careful of and a few quirks you'll learn in time (and they are documented endlessly on the web). You'll learn when to expect an undefined and when to expect a null, and it's really not that difficult. Sometimes things return NaN, and that's fine too. If you are getting NaN and you don't expect it, then it is likely a problem with your code and understanding of javascript, and not Javascript itself.

You should be careful to use var for variables inside a function to prevent global namespace collision. I use the 'object literal' design pattern quite often to 'namespace' my javascript code and it works nicely to keep the code tidy. Messy/bad code will have function variables leaking out to the global scope. You will see a lot of this if you look at code on random websites.

Never use 'eval'. Just don't. Read about it if you don't believe me.

Using the object literal pattern is also good practice because you should be using JSON as a data format wherever possible. Do not use XML. Never never never use XML for something you can do with JSON. Trust me, JSON is your friend in the world of web development.

Coding abilities are not equal, and coding styles are a big part of how people run into problems with Javascript. Messy coder, messy code. Not enough deliberate thought. I've seen it time and time and time again from new coders. I would have a problem too being new to other languages that I don't know, at first, until reading enough code to figure out what is good code and what is sloppy/bad code and which coding styles to adopt. That is something you must do to learn Javascript, and there are so many examples out there, there is no excuse.

The first thing you do want to do is use 1TBS indent style http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS - following this pattern will prevent you from a few common mistakes people make when coding Javascript, like using semicolons at the end of every line.

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.

Re:the trick is...

[Ash Vince]

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

Depends on the project, it can be. I am currently trying to create a SCORM 1.2 API interface in JS and that is a pretty major programming type task. Before anyone suggests using a different language please go and check what SCORM 1.2 is first. I have to do the work in JS as that is the language SCORM is based on.

Re:the trick is...

[Anonymous Coward]

Surely your example is trivial to convert to C++, even if the existing DOM libraries might have a different API at the moment? There's nothing about the language that prevents writing code such as:

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

or maybe

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

if you're passing around references instead. Not that I'd want to be writing that particularly snippet in *any* language, even Javascript.

Re:the trick is...

[holophrastic]

it's not about being-able-to it's about the entire concept based around it.

in perl, for example, that one line would actually auto-vivify the entire structure. Think about how much code would be required in C to create that kind of structure, let alone test it for various truths.

No no no Sambuca is your friend

[Anonymous Coward]

One shot to start the day.
One shot every 1 to 1.5 hours afterwards.

Anyone asks, then it is cough medicine (white or red galliano is good for this - it even smells like cough syrup and has just about the same effect..).

Black galliano samuca if you need to attend a meeting where discussing code and related solutions is required.

Save the scotch / whiskey / etc for when you get home.

Drink 1 glass of water 45 to 55 minutes after taking a shot of sambuca.

It makes the whole world a happier place, and in time you will start not to notice so much.

If you ever go back to real coding just decrease the dosage until you can handle reality in an unaugmented state again.

I have no sense of humour any more. But. They can't take my sambuca way from me (mostly because they haven't figured that I have it on my desk always)

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.

Having developed with Qt for many years, you're doing it wrong. Seriously.

Read more

[Art3x]

Douglas Crockford's JavaScript

JavaScript: The Definitive Guide

Try codeacademy.com

[Anonymous Coward]

I don't know how to rate the utility of this recommendation, because I am for the first time in my life learning how to code, but I'm doing so here. www.codeacademy.com. Every week they release new lessons and projects in JavaScript, and eventually will cover Ruby and Python as well, and it's free. I hope this is of some use to you.

young whipper snappers!

[Anonymous Coward]

Get off my lawn!

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.

Leave your assumptions behind

[PeterHammer]

In all these years and hours spent in compiler madness and dependency hell you never wondered if there had to be a better way? Keeping track of memory and pointers, or objects and threads? Compiling code? yuck. You may have to drop some acid or go off to an ashram and THEN you'll be ready to embrace the psychodelic world of callbacks and prototypes and json.

Some more serious advice: CSS and HTML are best left to specialists or you'll lose the little hair you have left. You will want a basic understanding, in particular, how they relate to the document object in js. MSDN and Mozilla have decent refrences, as does W3schools.

As for js, don't let the similarities with Java or C fool you. You'll only be wishing for native inheritance and type safety which you will never have. You'll have to embrace some new paradigms. Given your background, and after reading up on the language, I suggest you examine the sources for YUI3 or jQuery or preferably both. Then examine the source for Facebook's all.js to grok the Hacker Way to JavaScript. That will give you a good sense for the cabilities of the language and how to interact with the aforementioned document object to manipulate a webpage. You'll also have an understanding of three of the most important js libraries to know.

It's not the language

[Animats]

As a language, Javascript is easy. The hassles all come from dealing with the environment it runs in, which is usually a browser. You're making calls to a big, frequently updated, multi-platform thing that almost works. As someone else pointed out, the big headache is testing. Cross-browser compatibility is getting better; you can probably ignore the horror that was Internet Explorer 6 for any new work.

The big difference for someone coming from C is that you don't have to devote half of your attention to worrying about the two big headaches in C - "who owns what", and "how big is this array".You can afford to be more aggressive about data structure design.

Javascript is uglier than Python but less ugly than Perl. The JIT compilers are now quite good, and performance is better than you might expect. A huge number of people program in Javascript (although many of them not very well) so it's not a particularly valuable skill.

I'm currently writing in Javascript (browser add-ons), Python (server-side) and C/C++ (embedded control). After decades of C/C++, I think we should have moved to something better by now for low-level programming. Python is clean, but the implementations are slow. Javascript is in the middle, and adequate for what it's usually used for.

Another word or 3

[Anonymous Coward]

GWT (Google Web Toolkit). Write/debug in Java (Eclipse), have the final GUI working in browser.

thanks

[Anonymous Coward]

No sip no deep! Perfect article. Thanks. The last paragraph impressed me the most. It ringed a bell from something familiar on hahaped.

GWT

[Palantar]

From the source: Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. GWT is used by many products at Google, including Google AdWords and Orkut. It's open source, completely free, and used by thousands of developers around the world. You'll still need javascript eventually, but about 99% of my current (quite large) html5 web project is written in GWT. 10's of thousands of lines of code and hundreds of thousands of users, and it's quite rare that anything actually breaks. Go static typing and Eclipse tooling!

Re:Any rational programmer is anti-JS

[Anonymous Coward]

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

Funny?

[Anonymous Coward]

And I already used all my fucking mod points.

Fuck the funny mod, this post should have been informative/insightful.

I would personally recommend a shot of Stroh 80, but like the original asker, I'm old and can't do that stuff anymore. But it still smells ohh so good. But alas I'm relegated to the likes of Kaiun, Jack, The Macallan, and similar as my regular grog. (And no that's not a mix.)

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.

Old School Developer

[Anonymous Coward]

I've been coding for 25 years and don;t have any problems with JavaScript/PHP/HTML compared to C/C++ etc...

It's all about your mindset, it doesn't matter wether the language is strongly typed or not, yes a strongly typed language will find a lot of your bugs at compile time, however if you are introducing lots of bugs into your code then you need to learn to code better, that's not a good excuse for not liking JavaScript.

A bad workman will always blame his tools.

95% of the bugs in my code are logic related where I haven't thought things through properly but then when you have algorithms that can run to several hundred lines of code it's easy for that to happen, a compiler does squat to help with logic, I can look at JavaScript or any other code I have written and I know exactly what each variable is used for, mainly because of how I write my variable names, strong typing within the language makes no difference to me and I have never understood that argument.

Javascript or Python for macros

[SgtChaireBourne]

the existing data was in Excel and the destination of the processed data was also Excel, so it had a pretty strong homefield advantage, but the Macro code was really specifically purposed and very inflexible, to the point of pushing back on the requirements a little. C++ on Qt and Python on WxWidgets were more or less neck and neck for ease of coding and flexibility of product,

Then next time take a look at LibreOffice. The macros can be coded in Javascript or Python.

Re:Javascript or Python for macros

[JoeMerchant]

OpenOffice is on every PC that I setup for anybody...

That doesn't change those people who "won't mess around with that open sores garbage" and insist on an $800 MS Office install before they'll put down their coffee and think about working.

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/

I'll respond from a different angle

[Anonymous Coward]

Let's leave the advantages and disadvantages of the language features aside for a moment and approach it from an alternative perspective such as how a programmer can accomplish tasks and feel confident their code is solid.

In his native environment, code is developed and compiled and once it is in compiled form, the state of the code is more or less known (assuming he used decent practices such as unit tests and such). He is transitioning to an environment where the state of the code is entirely unknown and even until recently with the much more strict definitions of how HTML5 should be represented in DOM, the state of the runtime was extremely hard to know.

I think what he is looking for which would make the world of difference is if he attempts to adopt the test driven development style of coding. This way, as he codes, instead of compiling, he would instead execute his tests to make sure his code is sound. Of course, test driven development can drive many people utterly insane, especially since a person finds themselves wanting to write tests to test their tests. But using test driven development, you can press a key in the IDE and get the feeling that you have compiled successfully or failed in a given case.

Languages like EcmaScript which (similar to Ruby and most other interpreted languages) are a nightmare to people who expect their code to be compiled and that all link issues are sure to be resolved at compile time. Also, the dynamic nature of languages like EcmaScript can make a long term C++/Java programmer extremely grumpy since we old fellas see many of the techniques employed in these languages are hackish... as if the language was made more dynamic to avoid adding basic features which function better in compiled environments.

The real answer to the issues here is that using other languages that compile to EcmaScript is a great idea for people who don't like the dynamic prototyped nature of Ecma. There are some great solutions for C# and for Java to Javascript out there. The problem with those systems is that their learning curve can be high since C++ developers often don't like having to depend on weird tools for things like UI.

Of course, it would be best to learn to program in Javascript if that's the user's goal, but depending on what you're coding Javascript can often be a suboptimal solution. I personally have been coding an H.264 codec that will run in Javascript, WebCL and WebGL when it is done and frankly, Javascript is a truly terrible language for this, so I'm experimenting with moving the code to something strongly typed and compiles to Javascript.

TypedJS

[Anonymous Coward]

http://typedjs.com/ will make some of the debugging more bearable.

Career options

[Anonymous Coward]

Would you like fries with that?

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?

Re:Any rational programmer is anti-JS

[Anonymous Coward]

Everyone that has modded this one up should feel ashamed because it is not "informative" it is just plain wrong. No arguing. A 10 second web search would have made that clear.

Yes, yes. I must be new here.

Flawed Assumption

[Anonymous Coward]

Jack of all trades, master of none. If you are making a decent living doing what you do, on platforms that don't look like they are going anywhere for the next 20 years or so, why change?

I code in lots of everything. Most of my work is database oriented, so I do a lot of SQL, MySQL and Access query writing. I also work on the interfaces for these databases, some are web based and others are application based. So, I work a lot with PHP, C++ and Java too. In my experience (which is comparable to your own in terms of length) I find that because I do all these things that I tend to lose specialist jobs. People who want an application done entirely in C++ have said to me in the past that they are worried that my company would not be able to handle a large project of that nature.

When you specialize you open the door to larger earning potential. When you specialize in generalized disciplines (as I do) you open the doors to more work, but less quality work. The trade off, in my experience, is not worth it. I have learned a lot more, spread myself out and not focused on a specific discipline and the result is likely an identical earnings potential but with more effort put in to get there.

Javascript - the customer is...

[Anonymous Coward]

Javascript (aka ecmascript) is friendly to those who want to implement scripting in their application not to those who want to write scripts... got it?

Makes a lot more sense now doesn't it?

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.

Re:Any rational programmer is anti-JS

[Anonymous Coward]

> I mean, where's your GC?

std::shared_ptr f = std::make_shared();

Before going any further ...

[DiogoBiazus]

Understand the Javascript language, because it is a simple, yet powerfull language on its own. So, before digging deeper into libraries and tools, take some time to read the javascript garden, which will give you the dirty parts: http://bonsaiden.github.com/JavaScript-Garden/ And, as previous posters already said, the Crockford site which will give you good insight into good practices and useful patterns: http://www.crockford.com/

C.C++,Java Strongly Typed?

[Ada_Rules]

Wow. Now that is some drifting of the (english) language. While it is true that over the years, the weak typing of those languages has been slightly strengthened and it is true that some languages such as Javascript are even more weakly typed, it is really a stretch to consider C,C++ and java as 'strongly typed'. Of the bunch I suppose calling Java strong typed is probably somewhat fair but really, you've been swimming in a weakly typed pool your whole life and are just wading down a little bit more into the deep end and this point.

Ada is strongly typed. C is not.

But in any case the advise for living with Java script is the same advise I give people that are used to C++ and trying to get used to the 'strong' typing of Ada. You really need to work on thinking in your new language and not cling to first thinking of the solution in your old language in your head and then translating. There is not really any magic to doing this other than writing a lot of code AND trying to not let emotion get in the way.. Once you've picked up the tool, use it.

Re:C.C++,Java Strongly Typed?

[_0x783czar]

Not that I'm disputing your statement, I'm too much of a n00b to do so, but I'd be interested to know what your basis is for making that claim. It's a fairly standard claim to call C, C++ & Java Strongly typed languages.

CoffeeScript

[Anonymous Coward]

I've been using coffeescript for a while now, and quite surprised it hasn't been mentioned yet.

http://coffeescript.org/

jQuery + Douglas Crockford

[oldCoder]

1. Read everything Douglas Crockford has on his JavaScript website. Use his jslint program. Down the road, read the code of his jslint program, I suppose. Buy and read his book. It's also available for the Kindle. Read the whole book twice. Basically, the lesson is don't make JS try to be Java, it only causes headaches.

2. Get a good JavaScript book for the language itself, this listing of JavaScript book reviews recommends the Wrox book, but I haven't read it, I use the 6th edition of the Flanagan book. See the link.

3. It's a language that, along with HTML and CSS, needs you to have a great memory or a good IDE that will prompt you for the allowable names. You can get a version of Eclipse pre-built for JavaScript, and you can get the Active State Komodo Edit program, both free. They say the Komodo IDE is even better, but it's expensive and probably not as complete as the (free) Eclipse.

4. You can get a version that runs on your desktop like a shell or perl/ruby/python will, but it isn't necessary. I know you can easily get a version of Mozilla SpiderMonkey that will do that.

5. Don't use the double-equals comparison operator, it's too confusing. Use the triple-equals operator ( "===" ), it's a pain to type but it's more straightforward.

6. Be wary form whence you copy. There's a lot of terrible code out there.

7. Use jQuery after your first two or three practice web pages, and after you've got CSS under control. This means also get a good CSS book. I guess start with the 'Lie and Boss' book, even though it's old.

Re:My boobs are my toys

[Joce640k]

You meant 'moobs'?

Re:Any rational programmer is anti-JS

[rmstar]

> I mean, where's your GC?

std::shared_ptr f = std::make_shared();

Precisely! :-) That's not a GC. I'm tempted to say something about what happens to a GC when it is subjected to the horrors of mordor, but I think I'll refrain.

Poor programming

[Anonymous Coward]

In my opinion you are a poor programmer. Don't take it personally as 99% of programmers today rely on compilers to double-check their work. When I started out in the 70's we were taught how to program without errors. The reason being was that it took time and money to complete a compilation. While compile times are extremely fast relative to historical comparisons, and dependent upon other factors, in fact each compile costs you more time than you realize as you stop developing/thinking, click the buttons, wait to see if the slot machine gives you three cherries or lemons. When you get lemons your mind starts racing to find a solution to the new problem and it is distracted from the goal.

While this all may be true, I agree that Javascript and the likes suck and are annoying at best to program in. For if you are going to have it loosy-goosy when it comes to errors Javascript development environments/tools need to provide some better error messages.

My advice: Grow.

[Millennium]

Being a generalist isn't about knowing lots of languages: it's about knowing a lot of different ways of doing things. As long as you restrict yourself to the paradigms of C and C++/Java, you won't be able to do that. Bite the bullet and learn the JS way of doing things, and while you're at it, pick up things like Scheme and Haskell. Heck; even AWK could be interesting for this exercise.

Every new way you learn of doing things and approaching problems will make you a better programmer in all of the languages you know. That incudes C and C++/Java, and it also includes JS/HTML/CSS. It's also what being a generalist is really all about.

Eclipse + Chromium

[edxwelch]

I suggest Eclipse IDE for JavaScript Web Developers: http://www.eclipse.org/downloads/packages/eclipse-ide-javascript-web-developers/heliosr
and Chromium Eclipse Debugger: http://code.google.com/p/chromedevtools/

Everyone else seems too busy engaged in the language flame war to answer your question

Old school programmers didn't have dynamic typing?

[meiao]

Smalltalk been around for quite a while. At least a decade longer than Java.

CoffeeScript

[Anonymous Coward]

Try CoffeeScript. It's well designed, very easy to learn and highly efficient. It compiles to JavaScript and is easy to debug.

Re:Any rational programmer is anti-JS

[hexagonc]

I prefer to have syntax beyond parenthesis.

What other syntax do you need? Some people are never satisfied.

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

[Anonymous Coward]

Sigh. Just because a language has hot over-hyped feature "x" (which in this case is closures), doesn't mean it's a *good* language. JavaScript is certainly usable, but it's not a good language. I think of it like FORTRAN. A lot of awesome apps were done in it, but at a cost... It's time consuming and error prone compared to other languages. It'll need to be supported for a long time, but for new development it needs to be replaced with something modern.

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.

Learn Perl

[Anonymous Coward]

Learn Perl

Re:Open Source Code

[Ash Vince]

The day I trust others to write code better than me is the day my work becomes just good enough. There is not a lot of vertical mobility writing good enough code.

The attitude that you are a better coder than all your peers does not go over well when you start working as part of a team. If you want a long successful career as a coder you need to get used to working in a team, and that often means relying on other peoples code to work. You may even one day become a technical lead where you have to trust other people to write code, that means also letting them make their own mistakes and learn from them.

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

Use Google Web Toolkit

[Anonymous Coward]

Google Web Toolkit runs on JavaScript, but you (the programmer) use Java instead. It makes life much, much easier...

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

[JasterBobaMereel]

As always learn the basics of all the usual suspects, learn at least one if depth, preferably more than one

Then use the most appropriate one for the current project ...

The OP is of the "I'm a C/C++ programmer, how do I use Javascript to program in C++ ..." school ...

QooXDoo

[Navbot]

I can't really help with the strongly typed bit. But for a C++/Java guy doing GUI work I think you might like the QooXDoo library. It sort of compiles the javascript with a python script. The python compiler script will catch some mis-typing errors but certainly not all, you still have to be on your toes. However, what I really like about QooXDoo is that it frames HTML GUI development in a style that is reminiscent of Java or C++ widget libraries. The system has really allowed me to be productive at a level I would not have been able to tolerate previously.

GWT is the answer

[Anonymous Coward]

JavaScript is little more than an ugly bandaid - don't go there.

do not force javascript to be c

[Anonymous Coward]

You're falling into the trap of trying to make it into what it is not. You can turn screws with a pocket knife and you can carve with a screw driver. You won't get good results.

Re:Old school programmers didn't have dynamic typi

[Skapare]

Dynamic typing was hard to do when your code was translated to hardware machine language, since different data value types had to be handled by different sequences of code. Static typing is actually the legacy approach, and the crutch upon which weaker coding-time validation methods depend on.

Im confusedI

[O('_')O_Bush]

I don't quite understand what the trouble is. If you truly are an "experiencd" java/c/c++ developer, then you should also be fluent in shell scripting and perl from all the debug/build/log parse utilities you've written to make your life easier (and that have a similar paradigm).

That is, unless you developed only on Windows, in which case there is a much bigger problem that needs to be corrected first, before you even *think* about tackling the "future" through iTechnology.

Re:Any rational programmer is anti-JS

[Anonymous Coward]

Define "less powerful". There's nothing that can be done in one language that can't be done in the other.

Perhaps you actually mean expressive or something like that? That's quite possible, but they're different tools for different problems.

Thanks!

[DocDyson]

OP here. Wow! Thanks for the amazing and insightful responses, everyone.

As I read the comments, many of them reminded me of an old programmer's aphorism: "You can program in assembly in any language." I need to stop trying to program in Java in JavaScript, get past the superficial syntactic similarities, and immerse myself in JavaScript and its paradigm to learn to "speak it like a native."

I had already discovered Douglas Crockford's JavaScript: The Good Parts and jQuery but I will grab some of other books and learning resources. The explanation of how the various other frameworks, like MooTools, CoreJS, Dojo, ExtJS, etc., relate to each other was also helpful in understanding the overall JS ecosystem.

Finally, I will grab JSLint, JSCoverage, and QUnit (as one poster said, "QUnit is now your compiler"). I've been oscillating between Komodo and WebStorm, but neither feels quite right for me so will give Aptana a look.

Again, thanks for all the feedback!

Re:Any rational programmer is anti-JS

[Anonymous Coward]

To each their own. To me, GC is what happens when memory management is dragged through mordor.

I've programmed in countless languages over many a year, and never once have I missed GC in C++, whereas I've many times been annoyed by it in other languages. But then, I'm a bit of a control freak. So yeah, to each their own, no need to make derisive or condescending remarks about a language just because you don't like it.

Don't fight it.

[BurfCurse]

I was the same as you. Embrace it. And use backbone.js.

Just go with it

[morgauxo]

I learned C/C++ and Java first. Then PHP/Javascript. I remember weak/no typing feeling so strange! It took me a while just to 'get it'. Now I program C# at work but still code PHP from time to time at home. I miss weak typing! Strong typing really does suck IMHO. It seems like 2/3 of my code now is just checking that data will 'fit' in another type, casting it, checking that the casting succeded...

I know a lot of people defend strong typing because it is supposed to somehow save them from writing bugs. The excuse I usually hear is something about you might 'forget' what type a variable is and try to misuse it. It seems to me you should know what that variable represents before you try to use it for anything and the 'type' should come naturally from there!

One of my favorite patterns in PHP is to fetch a list of things by id number. Then I have an accessor that first checks to see if what is stored is a number or an object. If it's a number it fetches whatever information that id represents, wraps it in an object and puts it back in the very same variable that used to hold the id. Then it just returns the contents of the variable. If it is already an object it can skip the fetching and just return the object. Of course you can implement Lazy Fetching in a strongly typed language too but I just like that neatness of having one variable which holds either the id or the object rather than two of two different types. So long as I only access it through my accessor method (which PHP has __get and __set for which I really like) I don't have to ever think about what is actually stored there. It will be an object if and when I need it.

Of course I'm on a tangent now, you are less likely to do something like this in javascript but my point is that loose typing can be really nice once you get used to it.

Re:Any rational programmer is anti-JS

[Anonymous Coward]

Indeed. It should damn well be compulsory for every programmer to learn at least two programming paradigms. And I don't mean just the theory of them, but actual practical knowledge and experience with at least one language adhering to the paradigm in question. While I don't presently do much functional programming at work, for instance, I find my time with Haskell invaluable and very enriching. I'd be a worse programmer for not having that knowledge, even in my present line of work.

Re:Any rational programmer is anti-JS

[John Courtland]

The shit are you talking about. C / C++ and Java do not have closures. Period. They have things that sorta kinda resemble closures but they are not them.

Re:Any rational programmer is anti-JS

[John Courtland]

Closures are the mother of all abstractions. Any other abstractions can be made from them, so maybe you should learn yourself some comp sci before you sigh.

Re:Any rational programmer is anti-JS

[John Courtland]

I implicitly meant "of the languages you were discussing" which are C C++ and Java. Sorry I wasn't verbose enough to keep the context fresh for ya.

The future is a 10+ year old technology?

[Anonymous Coward]

I was using Javascript in 96... cool kids like me use facelets and a component library.
Primefaces is pretty good. (there's also richfaces and icefaces)
Javascript is just something you spackle the cracks with now. (Like a key blocker or something)
Javascript was always a bitch to get it to work against multiple browsers and AJAX made it more nasty.
But if you use a component library it takes care of all that for you.
Then you can concentrate on the design and less about what's going on under the hood.

Re:Dynamic typing is paradise. As is static typing

[Qbertino]

You're doing it wrong

1.) No kidding. I just started using C++/Qt a week ago, you remember?

  2.) I was exaggerating little for the fun and effect. But I think you understand. :-)

Still, thanks for the heads-up.
I'm a lot on Google and stackoverflow these days anyway, as you can imagine.

Got a fresh copy of this 1000 page beast sitting on my night-table and OReillys C++ Cookbook should be arriving today, and I'll have a lot of refactoring to do before I can call my little first C++ app finished and not totally embarrassing to show to a Qt/C++ expert. ... I'm currently trying to wrap my head around Signals and Slots, after years of only knowing Events and Listeners. I still don't get it, but people tell me once you do it's awesome and you don't want to go back. Sort of like using Git instead of Subversion. Ergo: Lots of work to do. ... *promises to stop doing /. for the day*

Closure Compiler helps

[Anonymous Coward]

I use Google's Closure Compiler to check usage in a fashion similar to how a traditional compiler would. It's found a lot of errors for me over the last few years.

Another benefit is it makes your code compressed, and makes it a teeny bit harder to copy without authorization.

Try Coffeescript

[Anonymous Coward]

Someone may have said this.. but check out Coffee Script.. its a higher level language that compiles INTO javascript.. with its own make files and coding conventions.. the plus side is it makes OOP in js not make you want to kill yourself. there are a few things it adds that makes it worth using, a foreach loop, some scope switching stuff.. but all in all its a REALLY simple language and you could learn it in a couple hours.

Use a web framework that generate JS underthehood.

[Anonymous Coward]

JSF 2.0 or Java FX are java framework to make client side "view" portable.

The Project Avatar will port your view to any html 5 compliant browser, for any kind of device (intelligent phone, tablet, mac, windows, linux, over the web and so on).

Unless you really need to use it (because someone ask you to for your living), you would be in better shape to use JAVA stuff to make anything you want to "port" over any device without major pain.

RIA and Web 2.0 apps don't need to have spaghetti JS and html to be maintained... they can be JAVA apps that are easier to maintain over the long run with a working corporate giving you the tools to port your app to the new "shitty" device UI of the month.

For garbage applications, that have short lifespan, it's really fine. But for big fat corporate applications, it's the kind of mess (JS + html) that any developer want to "flee" for greener pasture.

I'm OO, and I wrote CAD in JS

[Anonymous Coward]

I recently was on a project where I wrote a CAD package in C#, C++, Flash, and Javascript. With so many different UI's I had to keep things as similar as possible, and what I learned was that if you code JS in a certain way -- using only a subset of what it is capable of, you can treat it just like OO and keep your code and methodologies portable.

1) If you are writing a web app, make it one HTML page. This breaks the forward and back buttons, but sometimes this is okay, and you can trap events and take control of them if this is a super critical issue.
2) Once your app is one page, then you can think of it like a normal event-driven Windows app. It works just like WinForms, Swing, etc! State is kept on the client side, you get button click events, and you modify the HTML DOM to pop up windows, add controls etc.
3) Make separate little HTML + JS files as your "controls". Make say datagrid.html with all the datagrid functionality right in it. When you want to popup a datagrid control, dynamically load datagrid.html with jQuery and write it into the page. The inline JS will come right with it! Presto, you have controls!
4) Aside from loading the initial HTML page, subsequent controls, only use the server connection for data! Do everything via web-services.
5) Don't use the full on prototype-system. Use it only to emulate OO. Classic inheritance is a subset of prototypical inheritance, so if done correct, everything works exactly the same way.

At this point your JS app will look exactly like a conventional database driven client-side app! I ported 99% of my code line-for-line, keeping all the same class names etc, and was able to use this technique to keep a roughly 20,000 lines code-base consistant across C#, JS, and Actionscript. If you think of HTML+JS as MXML+AS or XAML+C#, it will behave exactly the same way!

Beyond the mental shift, I find the sticking point for most people is correctly implementing #5, so to help, here are 3 files showing inheritence:
1. VectorNd.js - an Nth dimensional base close for Vector2d, 3d, etc - http://pastebin.com/NFD34Hcp
2. Vector3d.js - a strictly 3D subclass of VectorNd - http://pastebin.com/B7henwas
3. The clone() function used by Vector3d.js - http://pastebin.com/Bd3QRqGE

Once you wrap your head around it, the inheritance model described above is exactly analogous to traditional OO, and you can even have getters / setters in JS. The old-fashioned event-driven Windows-style app has been around since the dawn of the UI, and despite HTML5's painful birth, I'm convinced HTML5 applications will work their way back to something like it, because it is the most logical way to handle the problem.

I feel some harsh flames coming on, but before you mod me down, please keep in mind this was an honest attempt to answer the author's question as he asked it :)

Re:An Old-School Problem - ditch the IDE

[b4dc0d3r]

I think it is an old-school problem, and can be solved in an old-school way. Write everything in Notepad for a month. No IDE, no auto-complete, no projects. JavaScript will instantly make sense, or at least more so than it does now.

I think it's the Java that spoils the fun. Going C/C++ to JavaScript was not an issue for me, but that's because I do a lot of editing outside of an IDE anyway. But that's just my experience.

Write a basic HTML page, seed it with expected data, then write your script around it. Load it locally and run it in IE/FireFox/whatever. Then take your functions and put them in your project. Advantage - you only need a few more unexpected data points to make it into a unit test page.

Yes write more code, but do it differently. Solve a non-javascript problem in javascript, just because it's there. Make a random dice tossing page that actually shows dice that look like dice. But do it in a simple text editor. Get used to the language, how it "feels" to type it, how it looks when it's correct and when it's not.

You Can't Get There From Here

[ios and web coder]

As a long-time C/OC/C++ guy, I regularly get horrified by JS.
However, JS works for the limited context of a Web browser. I'm not thrilled with the way it handles OOP, and I think it's awkward, but I've gotten pretty good at messing with it.
Here's a bit of code that I love to show C++ folks. It demonstrates exactly how primitive JS is, compared to C++:
<script type="text/javascript">
function HiDare() { alert ('Hi Dare!' ); };
function DisplayHiDare () { alert ( HiDare ) };
DisplayHiDare();
</script>
Coders will understand instantly, and ROTFL.

Re:You Can't Get There From Here

[Anonymous Coward]

May be I'm not coder enough, but I don't see anything ROTFL-worthy here. Care to explain?

Re:You Can't Get There From Here

[ios and web coder]

The displayed alert (you need to run the code) shows what a "function pointer" is in JS.
It is the entire text of the function. There ain't no such thing as a "function pointer" in JS.
If you understand this, it explains a lot of stuff about scope and whatnot in JS.
As a compiled language guy for ages, and used to looking at stack frames and stuff, my jaw dropped the first time I saw this.

Chrome and Closure tools

[Anonymous Coward]

The web is a weakly typed floppy mess built on a flawed stateless protocol, but it's OUR mess ;-)

Chrome tools, STS and Closure tools minimise the pain.

Think of it just like WinForms or Swing

[VoodooTrucker]

I've been responsible for maintaining CAD software with client apps in C++ / C# / JS / Flash. Because I found commonality between all these languages, I was able to port the code quickly and easily. Some tips:
1. Keep all the state on the client side. This means put everything on one HTML page, then manipulate the DOM to add controls, etc
2. Create a set of HTML+JS controls (say datagrid.html for example), then use jQuery to load instances of these controls into the DOM
3. Aside from the initial page load and loading of your controls, the only other reason to call to the server is to save & load data via webservices
4. Classical inheritance is a subset of prototypical inheritance, therefor you can emulate it perfectly. See the below examples:
Base class: http://pastie.org/3341844
Subclass: http://pastie.org/3341846
Clone function: http://pastie.org/3341847

If you think of HTML+JS just like you would MXML+AS or XAML+C#, then your app works the exact same way! HTML5 doesn't have to be any difference from the traditional model, you just have to tinker around with it more to achieve the similarity, since there isn't really a built-in concept of controls. Lastly, install Chrome. Since there is no compile-time, this is your new IDE. If you go into "developer tools" you have all the traditional stuff: call stack, break points, watch window etc. You still have to write your code in notepad without auto-complete, but everything else you do right in the browser. You can even use the watch window to inspect what methods are on an object, so you can use this as a sort of "manual" auto-complete!

PS, before I get modded down, please see that this was an honest attempt to directly answer the author's question.

Messy, Messy, Messy.

[getagrip]

Javascript is just messy. When you intersperse it with html, it is just like the bad old days of interspersing your layout with the html. CSS was created to separate the layout from the html. Javascript libraries do the same thing. Look into JQuery. The separation of the Javascript from the html makes it a lot easier to see what is going on. Also, use debugging tools like Firebug and Firequery to track down what is going on in the code. Good luck.

Re:Any rational programmer is anti-JS

[Anonymous Coward]

Ever heard of C#, Objective C, Ruby to name a few

Incorrect

[toby]

Proper lexical closures (such as exist in Scheme and JavaScript) cannot be implemented in Java or C++.

Re:Any rational programmer is anti-JS

[shutdown -p now]

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

It's trivial, but it's also observable. One of the more common causes of leaks in C# 2.0+ is when a local variable is lifted to heap because it was captured by a closure, and a reference to said closure is left around even though it won't ever be run. With shared_ptrs, it's even worse, because you can also get a cyclical dependency that way.

Anyway, C++ mantra is "you don't pay for what you don't use". This means that, if your lambda never outlives the local scope (and most of them - when used as predicates or mappers for std::find_if, std::transform, std::aggregate etc - do not), it should not wrap locals into smart pointers, because that would needlessly decrease perf. On the other hand, they haven't yet come up with a good way to deduce this sort of thing automatically for the most general case. Hence, it's left as a choice to the programmer.

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.

Hacker-bushido

[curvedinfinity]

OP's use of the word tolerable makes it obvious that OP is not focused on how to use Javascript, but instead is focused on the hurdles of change. Fact is Javascript is not a hard language to use, and looks mostly identical to Java. That's not the problem and the OP knows it. The problem is the OP wants to do something the Java/C/C++ way as opposed to just doing it. I call this mindset hacker-bushido. So OP, you might have spent years practicing the precise way to cut a piece of bamboo with a sword, but now you're using a spear. Don't focus on using the spear the way you learned to use a sword, just kill people with it.

Re:Any rational programmer is anti-JS

[shutdown -p now]

Ruby is very functional - idiomatic programming in Ruby strongly encourages using higher-order functions and closures...

I suspect what you meant to say is that it's not pure - i.e. allows and encourages mutable state and intrinsic object identity?

Re:Any rational programmer is anti-JS

[shutdown -p now]

I don't think C is worth investigating in this context, since it's explicitly a lower-level language. That it lacks closures is kinda by design, it would simply be too "magical" for C.

C++ has lambdas as of C++11.

Wt toolkit perhaps?

[Anonymous Coward]

Not to detract from the desire to expand your toolbox, but have you considered http://www.webtoolkit.eu/wt as stepping stone into web application development? It essentially abstracts much of the CSS/DOM/HTML/Javascript hijinks away and allows you to think and develop in C++. It's modeled after the well known Qt framework.

Re:Any rational programmer is anti-JS

[TheRaven64]

In Objective-C blocks, locals that are bound are referenced indirectly via a pointer. This is pretty cheap in the on-stack case - the variable and the pointer will be in the same cache line - and when the block is copied (which happens automatically in ARC mode when you assign a pointer to it to the heap or a global) so the general solution works quite nicely. It is still possible to construct cyclic dependencies if the a bound variable references the block, but it's nontrivial.

I don't think 'you don't pay for what you don't use' is really the C++ mantra. Having worked on C++ compiler and library implementation, I would say that the real mantra is 'no feature may go into the language if it decreases microbenchmark results, even if it will make large projects faster'.

Re:Any rational programmer is anti-JS

[jcupitt65]

Matz has said several times that he doesn't like functional programming much and has no intention of adding things like ZF-expressions (list comprehensions), operator currying, all that stuff.

You're right that it has nice support for closures.

Re:Any rational programmer is anti-JS

[shutdown -p now]

In Objective-C blocks, locals that are bound are referenced indirectly via a pointer. This is pretty cheap in the on-stack case - the variable and the pointer will be in the same cache line - and when the block is copied (which happens automatically in ARC mode when you assign a pointer to it to the heap or a global) so the general solution works quite nicely.

Do you mean that the stack frame has a pointer to a memory location that's placed on the heap, and said pointer is what's captured by the closure? If so, then "pretty cheap" is still arguable. For one thing, you still have the expense of a heap allocation/deallocation - both time-wise, and also memory expense due to heap metadata. For another, you have those refcount updates.

It also leads to the next interesting question: how many heap allocations do you use for this? It's tempting to collect all captured locals and shove them off into a single struict to save on allocations. But now, if you have more than one lambda in the scope, and those lambdas reference different sets of locals, they will both hold a reference to the same struct. If one lambda references a large object (say, a collection), but has a short lifetime - e.g. does not outlive its scope, a fairly typical case - and then another lambda has a long lifetime (say, an event handler) but only references a single local int - that second lambda ends up holding the vector also because it shared allocation with the int that it needs. On the other hand, if you split captured locals into several structs, you get more allocations and more refcount updates.

C# implements something similar - it shoves all captured locals into a single class, and puts a reference to that class on the stack, and that's what all lambdas in the scope reference. As a result, the problem described above - memory "leak" when you have more than one lambda, and they end up sharing all captured variables in that scope even if they don't use it - is not uncommon.

In C++, on the other hand, I can make my own decisions. If I want a shared-closure-for-all-locals, I define a local struct and put in a shared_ptr referencing it, then capture that from my lambdas. Note that lifetime implications are explicit in this decision - lambdas are clearly capturing the whole thing, not individual fields, so it stays alive for as long as they stay alive. On the other hand, I could instead have separate shared_ptrs per each captured local, where that makes more sense.

Re:Any rational programmer is anti-JS

[Imbrondir]

I'm not saying it's a huge difference, but there certainly is one.

Python is my favorite language of choice, but I very often remember wrong the exact lambda syntax when I've had to use it, and by extension often avoid using it for that very reason. And the first time I read it in use I felt overwhelmed and had to google it. 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".

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

Re:Any rational programmer is anti-JS

[shutdown -p now]

It's the same old argument over what exactly "functional programming" really is, I guess.

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.

Re:Any rational programmer is anti-JS

[John Courtland]

I would say C is worth discussing considering the story is about a guy who is all C, C++, Java and some rhodes scholar AC up there said JS has inferior abstractions.

Also please make sure not to conflate lambdas with closures. It's pedantic but they are different animals. I don't know enough about C++11 'cause I had the good sense to flee from that shit in the 90's so I can't speak to the implementation of it's lambdas to know if they can close over free variables. Java, for instance has anonymous inner classes which can behave like lambdas, in a manner of speaking, but you are explicitly forbidden from closure.

Gladly avoid types

[Eravnrekaree]

My advice: forget about types. You are wrong to think that types are a debugging feature. They are not. Types were originally included for use in programming languages where there was no automatic memory alliocation and when memory usage had to be manually managed. With a VM language like javascript, this is no longer necessary, Some dynamically typed languages such as perl really have just one scalar type, a string, and there are several data structures and there are references and objects. All of the size types are simply unnecessary and actually created more complicated code. The size types do not prevent a wide variety of coding errors and really just not something that one needs to think a necessary thing to have for debugging.in Perl, in fact, is a much safer language than C because it lacks C's buffer overrun craziness, as well as cleaner code with less unnecessary typing mess to worry about. Perl automatically sizes its strings for data.

Excuse me...

[Anonymous Coward]

... but real programmers use butterflies.

Re:Any rational programmer is anti-JS

[shutdown -p now]

C++11 lambdas close over free variables, but you pick the exact nature of that closure yourself. You can "capture by value", meaning the local is simply copied into the lambda; or you can "capture by reference", meaning that the lambda will reference the variable in outer scope. You can mutate the variable inside the lambda in any case (unlike Java's anon inner classes, which only capture finals), but when you capture by value, it's the copy that is mutated. On the other hand, C++ doesn't do anything special to extend lifetime of captured variables - so if you capture byref and then the variable goes out of scope, you can't legally access it anymore - if you need this, you use a smart pointer instead, and capture that by value.

Also, I wouldn't say that Java anon inner classes are "forbidden from closure". They are more limited in terms of what they close over - in particular, they only close over finals, not just any random local. But I don't see how that makes them not closures - after all, in Haskell, all variables are "final" in a similar sense, yet Haskell lambdas are most definitely closures. There is an argument that AICs are not true closures because they don't close over everything that's available in the scope in which they are created - i.e. you can't write any random code at the point where AIC is instantiated, then move it inside AIC and have it working in the same exact way. But that involves more than variables - for it to work, it'd have to also close over the context of "return", "continue" and "break". If you use that definition to determine whether something is a true closure, than JS doesn't have closures, either, since it doesn't handle any of those.

The real problem with AICs is that they are extremely verbose to be used with higher-order functions conveniently.

I guess I'm lucky I played with Erlang

[msobkow]

After Erlang's dynamic runtimes, JavaScript comes across as a strongly typed language in comparison! :P

as an old C++ guy, javascript is ok, CSS sucks..

[bored]

I didn't find javascript to be unbearable. It didn't take to much time, and I learned how to make it do what I wanted. The ugly parts were all DOM related, and even that wasn't too bad once I got the basics. Most of the nasty issues had fairly straightforward workarounds once I found out they were there (for example, the relationship between DOM modifications being posted and when an event completes between browsers). Now there is jquery, which has pretty much hidden all the ugly DOM nasties, and makes javascript nice in most regards. I still dislike the OO model, but I can deal with it.

That said, CSS is an absolute abomination. I can't say anything positive about it. The general idea about separating the content from the layout is a good one. The problem is that CSS is so fundamentally broken that probably 4/5ths of everything I want to do, requires some nasty hack or is simply impossible without using javascript to position something on the fly. I guess my problem is that i've used so many GUI and print layout engines, that I expect there is a way to do things that I imagine, rather than trying to fit my ideas in the constraints of CSS. Nor do I like sprinkling divs all over the place to work around asymmetries in what attributes can be applied to existing tags. Worse yet, are the divs that need to be sprinkled as tag holders. Plus, the fact that I need to use a CSS preprocessor, for basic things seems insane. I also hate its inability to explicitly reference a parent or siblings with respect to simple layout concepts like rightof/leftof, instead requiring layer over layer of divs. I shouldn't have to screw around with the markup to do simple layout changes. I could probably write a hundred page book without even trying, on things that are wrong with CSS.

Frankly, I was so sick of it, I wrote a layout engine in javascript, that entirely replaced HTML and CSS, with a generic set of XML tags more based on traditional GUI concepts. I learned a whole crap load about javascript and the DOM doing it too. The sad part, is that I never really finished it. Its good enough to draw some simple overlapping windows, and allow the user to reposition them, click buttons, draw things, etc, but its not really good enough for prime time. A big portion of the problem is that its hard to do fast flicker free animation and drawing simply from JS. Sure I can draw a region, and a scroll bar, but when the user scrolls the region, it should be nearly as fast as doing it with just a normal browser and HTML. Doing all the drawing/layout with javascript makes this nearly impossible. Then the single threaded nature of the event system in all the browsers also tends to cause input lag if the redraw process gets involved.

Basically, in the end, there is a reason flash, silverlight, java web start, and random other plugins still exist. Doing heavyweight UI's using JS/HTML/CSS/etc is a PITA.

Re:Any rational programmer is anti-JS

[Anonymous Coward]

My GC? My precious!

Re:Any rational programmer is anti-JS

[Anonymous Coward]

Lexical closures in LISP date back to the 1984 release of Scheme. The original LISP had dynamic scoping, which isn't the same thing.

Runtime debugging with firebug

[Anonymous Coward]

Try runtime debugging with firebug. There is no substitute.

Ext

[Anonymous Coward]

Use Sencha's Ext JS 4 library. Awesome.

Read between the one line that matters...

[fzammett]

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

In other words: "Despite my 20 years of experience I've never been a particularly good developer because without my tools doing half the work for me I'd be all but useless to my employer. I can't really think for myself, have poor fundamentals and therefore when confronted with a technology that requires I actually have a clue, it's difficult for me."

Isn't it ironic that it takes something like JavaScript that so many still incorrectly consider a bicycle with training wheels to expose those that don't really know what they're doing?

I have 25+ years of experience and I can get the job done with multiple languages of multiple kinds on multiple platforms equally well. Know why? I actually know what I'm doing! Tools can make me more efficient, sure, but I don't *need* them to work well (and frequently I prefer *not* having an IDE constantly thinking for me). I learned a new language (Lua) in the past few weeks to the point where I'm now developing a highly complex mobile app with it and that's not at all unusual, transitioning to a new technology. Not hard to jump around like that when you're a *real* developer.

(Disclaimer: obviously I don't personally know the OP, so take this more as a condemnation of a far too many developers in general these days, not specifically of this guy... I'll give him the benefit of the doubt since I don't know him)

Career Enhancing Guidance

[Roachie]

Yea, I know you are an old-skool C/C++ Unix neckbeard that has to sit in the presence in Javascript code.

Pull up your big girl panties, quit bitching and get back to work.

Re:Any rational programmer is anti-JS

[Brian Feldman]

How is Ruby not very functional? How much Ruby have you done? OO features and procedural features are optional. You can operate strictly on lambdas and local variables if you wish.

Origins

[Anonymous Coward]

My opinion is similar to many of these professionals who deal with JS on a daily basis, however, to be clear I do NOT professionally write JS nor do I really know HOW.

However, I would suggest to you that you look not at how JS can be converted to your current programming style, but rather investigate the fundamental differences between your current programing languages and JS. As a C++ developer you are using a language designed to compile and run on the computers CPU. It has so many functions build in for fast easy programming. Yes, everything on a computer runs on the CPU, but that is not how I would think of JS as functioning. The languages you are used to compile to machine/byte code that is literally in direct interface with the CPU in an efficient manner. Think of Javascripts' "CPU" to be the browser it is running in. It is not "compiled" making it VERY difficult to efficiently check for errors in the code. You distribute it as source and unlike cross-platform languages that compile to byte code run on a powerful processor, it is run by the browser. This makes it very powerful insomuch as your code can execute on ANY platform with a web browser. However, you must respect that comes with limitations. Do not think you can use your C++/Java "tricks" to make elegant JS code.

JS was never intended to make desktop applications the way C++/Java are. It's (original [probably open to debate]) propose is to modify a web page. Well it is possible to make an entire web based application with Javascript, you do not need to. You are free to make server side back ends in anything you wish. Use JS for what it is GOOD at. You wouldn't make a Java applet to just change the background color of a web page, but JS does it quickly, efficiently, and elegantly. Because that's what it was designed to do.

I know this is probably not what you would like to hear, but I'd suggest simply learning JS in the same way that you learned your first language. Drill down into the APIs and explore what is possible. Learn "new" tricks. Truly amazing web pages can be build with it, but you can't bring the mentality of a web page being just the same old GUI front end to your application. Will you need to do "real" logic in JS for a web page? YES. Remember though that your logic is being processed by a web browser with a limited API and not a full fledged operating system. By remembering what the language was designed for it will be easier to understand it's limitations and what it should be used for.

In the current day programing world it is easy and fluid to mix different languages. If you really CAN'T get your head around doing logic in JS, just learn to write your interface in it. Use a back end. JS is not like the languages you are used to because it wasn't designed around the same mentality. Learn it for what it is and do what you can with it. If it ends up being too much for you just use a CMS for your web development, Joomla or Drupal. Let them handle the dirty work and program in the way you are used to. HTML5 et al. may be the future of the web, but other methods will be around for a long time. Maybe you should just wait to pick up JS until someone develops a way to give an IDE the tools you are used to. It's not like you will be "out of a job" because you can't write an HTML5 page from scratch, there are ways around it; many of which people have discussed in this thread.

Re:Any rational programmer is anti-JS

[Imbrondir]

Yes it's a definitely a balance. I actually miss the a++ feature in python. It trades brevity and expression for some (minor) readability and newbie friendliness. In the case of lambdas I simply personally favor the readability of the JS solution in front of the Python brevity. Probably a lot due to allowing multi line lambdas also (which is of course another subject if it's good or bad by itself). Attempts to compress useful code down to a one liner often ends up with very hard to read code.

In any case I'm not trying to say the JS solution is overall better. Just simpler and easier to read.

Re:Any rational programmer is anti-JS

[shutdown -p now]

"Easier to read" is wholly subjective. In my eyes, the following:

xs.fold((x, y) => x + y);

is way easier on the eyes, and hence easier to read, then:

xs.fold(function(x, y) { return x + y; });

which has a lot of syntax noise that only distracts from the actual operation that is being performed here (i.e. fold with +).

For multiline lambdas, yes, the difference in syntax is not as important. Though multiline lambdas in JS are usually either event handlers (which are usually better made named functions); or else you're doing async programming with callback chains, which is better done using a language feature that unrolls regular code into CPS, a la Python's "yield" or C# 4.5 "async/await".

Learn it then scrap it

[Anonymous Coward]

As an experienced SE first learning javascript start by figuring out how to implement base classes and inheritance such that you can new up an array of child instances and modify one without affecting the others or the base. Once you've mastered that then throw that concept out and realize that javascript is not the appropriate place for such code.

Javascript is a browser-based language intended for use in manipulating documents. It will do more but don't do that; it's folly. The browser environment is transitory, there is no persistent storage and a simple page reload can easily discard all the data you've just built up. You have no reliable means to maintain state (attempts to do so using URLs are monstrous to maintain by hand).

Use javascript for what it is meant for, what it's really good at: manipulating the dom. Use it to make your UI interactive and reduce page loads where it makes sense to do so (be careful not to go ajax-happy, that's no good either as managing the history page-stack can be a nightmare in itself). Once the user does something that needs to be preserved, ajaxify that on back to your backend and return some fresh chunks of dom or a new page or whatever your application calls for. Let your backend do the work and javascript handle the display/view. It's good at that and bad at everything else.

To make matters worse, javascript performs terribly. Chrome has a much faster js engine than, say, firefox or IE, but it's still very easy to tip over with too much javascript. Keep it thin.

Good luck ~

Coffeescript

[Anonymous Coward]

I suggest you look at CoffeeScript. It is a compiles to JS, but cleans up a lot of the difficult syntax.

Re:Any rational programmer is anti-JS

[Anonymous Coward]

I mean, where's your GC?

shared_ptr

GWT (Google Web Toolkit) rocks

[mr_zorg]

+1,000 me too!

GWT has really made me enjoy client side be programming again and enabled us to do some VERY sophisticated web apps. As for the GUI widgets and layout abilities, yes, they are a little weak. But throw in a professional widget library like ExtGWT (aka GXT) from Sencha and you're golden - it's a GWT implementation of their very popular ExtJS library.

Re:Any rational programmer is anti-JS

[jcupitt65]

Ruby is Smalltalk meets Perl, really, it's not much like Haskell. You can do some functional things in it, but many nice features of functional languages like Haskell are not present. Currying, ZF-expressions, argument pattern matching, ...

I was struck by Matz's comments on Ruby when reading up on why list comprehensions never made it in.

It's too functional so that I'm afraid it would not work well with OO nature of Ruby. Maybe it's matter of notation.

http://markmail.org/message/agv5qlyrh2hhncuw (I can't find the original source, annoyingly)

Re:Any rational programmer is anti-JS

[TheRaven64]

Do you mean that the stack frame has a pointer to a memory location that's placed on the heap, and said pointer is what's captured by the closure?

No, that would be silly. The stack frame contains a structure containing metadata about the variable, including a pointer to the variable. It also contains the variable. Both the pointer and the value are pretty much guaranteed to be in L1 cache, so access to them is fast. When you retain the block, the structure and the variable are copied onto the heap, and the forwarding pointer is updated. At this point, the access has a bit more overhead (and the copy operation also adds a bit).

In this case you also only pay for what you use, but more importantly you only pay for it when you use it, not when you might use it. The caller does not need modifying if the callee decides to keep the block after it returns. The Objective-C version solves the problem in the general case, while the C++ solution places an extra burden on the programmer and introduces a leaky abstraction. I could easily modify something that took an Objective-C block to run asynchronously or use lazy evaluation. Doing the same with C++ lambdas would require modifying every caller.

It also leads to the next interesting question: how many heap allocations do you use for this?

This is a good question. Currently, we use one structure per variable (for byref, as opposed to copied, variables - immutable variables are all shoved into the block structure). There is some possibility for optimisation there, but no one is working actively on it because it's very rarely the bottleneck (unlike C++ designers, compiler writers are expected to actually profile their code before optimising it).

JSR223 and Rhino

[leftbrainstrain]

JavaScript is typically used in client-side web programming like you mentioned, but there have been many other applications of it. Since you're a Java programmer, an interesting exercise may be to try and write some JavaScript to run on the JVM. Java 6 includes a customized version of Rhino as a Java Scripting API (JSR223) engine for JavaScript. You can invoke JavaScript from the command line using the jrunscript command that's now part of the JDK. I've been toying around with this just to learn the JavaScript language. Just to warn you, dealing with Java's method overloading and reflection can be painful in JavaScript.

Re:Dynamic typing is paradise. As is static typing

[Anonymous Coward]

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

I'm assuming you are speaking from actual experience here

I feel sorry for you

[Anonymous Coward]

Coming from rigidly structured languages, you're going to have a hell of a time with JS.

I hate JS's fucking type system. It's inconsistent and awkward to use. It's approach to Object Orientation is mind boggling; the syntax is awful. Every time I want to use JS's OO facilities I have to look up a guide because it's so counter-intuitive, especially coming from a C/Java background.

Luckily, JQuery soften the sharp sting of having to develop JS. I use it every day and I don't know what I do without it.

Crockford

[Anonymous Coward]

I highly recommend the Crockford videos (esp. Google IO one). They tell where JS comes from and what it's good and bad parts are. I started there after being a DITW systems guy, but now I love JS. Or more precisely, I don't love it, but I enjoy it, and it's doing good things for me.

Try a OO / inheritance approach using prototypes. Relish the flexibility of FAFCOs and learn closures. Fast. Trust me you need closures to maintain scope. Once you crack prototypeOO and closures, you can organize your code and write anything.

Also, if you're serious about not getting side tracked by HTML/CSS layout weirdness, use canvas. It gives you explicit control over your UI using a few simple primitives.

JSLint

[Anonymous Coward]

Tools like jslint are always good

http://www.jslint.com/

Step Four

[jman.org]

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.

I would recommend a re-acquaintance of the Scientific Method.

XUL

[NewYork]

http://www.xul.fr/en/ is a good starting point for old timers like us

The Chrome Dev Tools are brilliant

[samdutton]

I've replied to a comment earlier, but I'd like to give a big thumbs-up to the Chrome Dev Tools.

The Chrome tools are great to work with and at least as powerful as any of the other browser tools -- as this blog post shows.

If you haven't used them for a while, I suggest you give them another try.

(Full disclosure -- I work for Google.)