Ask Slashdot: Making JavaScript Tolerable For a Dyed-in-the-Wool C/C++/Java Guy? 575
DocDyson writes "I'm a dyed-in-the-wool C/C++/Java developer with over 20 years of experience. I'm making a good living and having fun doing back-end Java work right now, but I strongly believe in being a generalist, so I'm finally trying to learn the HTML5/CSS3/JavaScript future of the Web. However, I find JavaScript's weak typing and dynamic nature difficult to adapt to because I'm so used to strongly-typed, compiled languages with lots of compile-time error-checking and help from the IDE. Does anyone out there who has made this transition have any tips in terms of the best tools and libraries to use to make JavaScript more palatable to us old-school developers?"
A language that compiles to JS (Score:5, Informative)
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).
Javascript: The good parts (Score:5, Informative)
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.
Dart? (Score:5, Informative)
go assert yourself... (Score:4, Informative)
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 (Score:5, Informative)
That's an antipattern (Score:5, Informative)
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:A language that compiles to JS (Score:4, Informative)
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 (Score:5, Informative)
On the topic of languages that complile to JS, GWT [google.com] is very nice, especially if you're using a Java back-end.
Re:As a Javascript developer... (Score:5, Informative)
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.
GWT (Score:4, Informative)
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 (Score:4, Informative)
Use Google's 'Closure Compiler' (Score:3, Informative)
Firebug (Score:1, Informative)
It's a good time to look, but I wouldn't jump in (Score:4, Informative)
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 [amazon.com], Eloquent Javascript (free) [eloquentjavascript.net]... and I'm starting on Test-Driven Javascript Development [amazon.com], 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.
Re:GWT (Score:5, Informative)
Re:one word: JQuery (Score:4, Informative)
Re:Adapt or die (Score:2, Informative)
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:JS is not OO (Score:5, Informative)
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 [wikipedia.org] rather than class based. [wikipedia.org] Both are legitimate forms of object oriented programming, although class-based is more popular now.
Re:A language that compiles to JS (Score:4, Informative)
https://github.com/kripken/emscripten [github.com]
w/ emscripten, if you can output llvm from your language, you can run it in javascript.
Emscripten author claims 2-3x of optimised C.
Javascript: The Good Parts (Douglas Crockford) (Score:5, Informative)
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
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.
Re:As a Javascript developer... (Score:0, Informative)
Re:Going down in flames (Score:5, Informative)
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:Dynamic typing is paradise. As is static typing (Score:3, Informative)
... 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 [slashdot.org]
Re:Going down in flames (Score:5, Informative)
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 (Score:3, Informative)
Re:Going down in flames (Score:5, Informative)
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:Any rational programmer is anti-JS (Score:5, Informative)
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):
Re:Going down in flames (Score:4, Informative)
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 (Score:5, Informative)
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:Any rational programmer is anti-JS (Score:4, Informative)
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 (Score:5, Informative)
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.
He wants Google Web Toolkit (Score:5, Informative)
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:Going down in flames (Score:5, Informative)
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.