Four factors
Whenever I look at a programming language, I consider four factors:- Is it freely available?
- Is it an elegant programming language?
- Is it useful in practice? That is: Can I write cross-platform GUI applications? Does it have enough libraries?
- Does it have good tools, especially a good Integrated Development Environment (IDE)?
Is JavaScript freely available?
JavaScript is arguably the most open programming language there is: ECMA-262, its specification, is an ISO standard. That specification is closely followed by several implementations from independent parties. Some of those implementations are open source. Furthermore, the evolution of the language is handled by TC39 [1], a committee comprising several companies – companies that are normally competitors.Is JavaScript elegant?
Yes and no. I’ve written fair amounts of code in C++, Haskell, HyperTalk, Java, Pascal, Prolog, Python, Scheme and 6502 assembler. I’m also loosely familiar with Smalltalk, Common Lisp, Self and others. So I’m well aware that JavaScript isn’t the pinnacle of elegance. There are two kinds of things that tend to confuse newcomers: On one hand, there are true quirks, such as function-scoped variables (instead of block-scoped ones), limited loops and complicated constructor subtyping. But even in elegant languages, you have to get the hang of the style. In JavaScript that includes learning the quirks. On the other hand, there are unorthodox mechanisms, such as object-based, prototypal inheritance. Those are mainly a hurdle for people coming from other programming languages.But JavaScript has also many elegant parts. Brendan Eich’s favorites are:
- First-class functions
- Closures
- Prototypes
- Object initialisers and array initialisers
Language compatibility between JavaScript engines used to be a problem, but isn’t, any more, partly thanks to the test262 suite that tests engines for ECMAScript conformance. In contrast, browser and DOM differences still are a challenge. That’s why it is normally best to rely on frameworks for hiding those differences.
Whether or not you accept CoffeeScript as a way of increasing JavaScript’s elegance is a matter of taste. For me, JavaScript is not broken enough to warrant a different syntax and an intermediate compilation step. ECMAScript.next might eventually play a role that is similar to CoffeeScript: It will fix most quirks and provide more syntactic convenience. Classes [5] are one example – a feature that has been field-tested via CoffeeScript. But ECMAScript.next will be a true superset of JavaScript and there will be no need for compilation on modern browsers.
Is JavaScript useful?
If I program in a language, I want to be able to write cross-platform GUI applications. Doing so is always a compromise: you give up some quality in exchange for not being limited to a single operating system. In the past one targeted the major desktop operating systems: Windows, Mac OS and Linux. But we now have two additional interactive platforms: web and mobile. JavaScript is a great choice for the web and a good choice for mobile. For the desktop, free solutions are being developed (examples: AppJS, node-webkit), but they are not as mature as, say, PhoneGap.When it comes to libraries, there is still an unfortunate schism between client-side JavaScript and server-side JavaScript. On the server side, things are already close to ideal: The Node.js package manager (npm) offers both ease of use and a tremendous selection of useful libraries. I’m hoping that we’ll ultimately have an npm-like solution that works for both client and server. But for that to happen, client and server must share more system APIs.
JavaScript’s usefulness is helped by two recent technologies: Both JSON and NoSQL databases (such as MongoDB and CouchDB). Those databases usually tightly integrate JavaScript and JSON.
Lastly, there is shell scripting, which is practically its own platform. It solves problems that typically involve reading, creating and/or transforming files. Shell scripts are often throw-away code. It helps if you are fluent in the language that you write them in. Therefore, Bash and similar languages are not a good option for most people. It also helps if the language has many libraries (parsing file formats, manipulating images, etc.). JavaScript has become viable in this area, thanks to Node.js [6].
Does JavaScript have good tools?
JavaScript is getting better build tools (example: Grunt) and test tools (example: mocha). Node.js makes it possible to run this kind of tool via a shell (and not only in the browser). One risk in this area is fragmentation: we are in the process of getting too many of these tools. The Java community benefits from having few tools that are used by everyone.In the IDE space, JavaScript still has catching up to do. The gold standard for free IDEs is the Java-centric Eclipse. JavaScript being more dynamic than Java, more work and a different mindset are necessary to create an IDE. One promising new attempt is Adobe Brackets. For me, a good IDE is essential for using a language to its fullest potential. After having gotten used to the comforts of Eclipse, I found it difficult to leave Java behind, even though it is not a very succinct language.
The future
The next version of the JavaScript language standard is code-named ECMAScript.next. It will be finished by the end of 2013 and its final name will probably be ECMAScript 6. ECMAScript.next is an important next step to keep JavaScript relevant. It fixes many quirks and makes features part of the language that were previously implemented by libraries (examples: modules [7], classes [5]). Doing so is challenging, because ECMAScript.next must not break existing code, as it will be a silent upgrade for most users.Given that it will be years until we can rely on ECMAScript.next being there in browsers, I expect people to develop in ECMAScript.next on a modern browser, but to deploy two versions: An ECMAScript.next version for modern browsers and a version compiled to ECMAScript 3 for older browsers. For simplicity’s sake, one could even deploy only the ECMAScript 3 version. The similarities to CoffeeScript are obvious, especially in the latter case. Hence, some of its techniques and work flows can probably be adopted.
33 comments:
Also, JavaScript from a Haskeller's point of view: http://www.haskell.org/haskellwiki/The_JavaScript_Problem
Does it have good tools, especially a good Integrated Development Environment (IDE)?
IDE's make you stupid
Nice write-up :) Especially the progress in tooling (due to the success of node, imho) is awesome!
While I agree with you on most of your points, I see ES.next with a bit more skepticism. I feel, most of the new syntax (i.e. for modules, fat arrow) looks odd and out of place. While new features like block scoping try to rectify some of the quirkiest quirks they also introduce confusion and fragmentation.
Different scoping, different binding of "this", etc...
Also does JavaScript really need classes?
IDEs tend to be difficult to learn. But there is a great payoff – if and only if the IDE is well done: Source code becomes easier to navigate (e.g. via queries) and you can refactor (change method names etc.). I also like that I can click on a variable name and all of its uses are highlighted.
An interesting read, thanks. Perhaps a bit too negative.
It will take time for us to get used to ES.next. It looks alien at first, but it grows on you. The fragmentation cannot be helped, that’s the nature of the web. On the other hand, once it is finished, you should be able to live in an ES.next-only world where most of the quirks still exist, but are hidden. Again, similar to CoffeeScript. Then the knowledge of the language will be layered: ES.next-only is for beginners, a largely quirk-free subset of the language. ES full is for advanced JavaScript programmers and includes all of the historical “bad parts”.
ES.next classes aren’t really classes, but syntactic sugar for constructors [1]. Subtyping via constructors is complicated, which is why we currently have many inheritance libraries (that lead to incompatible code). Classes will hopefully make those obsolete.
I’ve written about arrow functions [2]. Their main benefits are: more compact syntax and a reduced need to think about `this`.
[1] http://www.2ality.com/2012/07/esnext-classes.html
[2] http://www.2ality.com/2012/04/arrow-functions.html
IDEs don't make you stupid. Relying on them INSTEAD of learning the fundamentals/languages/frameworks/APIs is what handicaps you as a developer. If you do learn them and then use a good IDE as an aid to productivity, then it is a great benefit.
Excellent post. Many of us who have worked with strongly-typed, compiled languages twitch violently at the thought of working with Javascript, but it really is the ultimate pragmatist's choice. I can't think of a language that shows up in more places. I've been exploring Node recently and find it very interesting.
I like to think of a good IDE as my little AI coding buddy. Not quite pair programming, but in the neighborhood.
“Many of us who have worked with strongly-typed, compiled languages twitch violently at the thought of working with Javascript”
— I’m one of you, I’ve been a Java programmer much longer than I’ve been a JavaScript programmer.
Interestingly, with modern JavaScript engines, how JavaScript is executed is not that much different from how, say, Java is executed. V8 even infers classes under the hood, to produce more efficient code. It’s a bit like driving stick versus driving automatic. As far as I know, the latter is even more fuel efficient these days.
“it really is the ultimate pragmatist's choice”
— True. I like that way of putting it.
> Does it have good tools, especially a good Integrated Development Environment (IDE)?
WebStorm is the best IDE for JavaScript I have ever seen.
It is not free but the price is really low.
http://www.jetbrains.com/webstorm/
I like JS and wrote tons of JS code but.., last year I am using statically-typed and compiled CoffeeScript only. And it's addictive and game changer too. I don't want to write classic JS anymore. Like Sinuhet the Egyptian, I want my glass full. (github.com/Steida/este)
I really tried to use WebStorm, but it sucks in many ways. Editor instead of IDE ftw. SublimeText is all I need.
Try code navigation with SublimeText cmd-r or cmd-p @/#
I consider it as much faster than anything I have seen in Visual Studio, Aptana etc. Also, I rarely use mouse for code navigation.
I like both. I think it is preference.
Axel, I love the Churchill quote! I totally agree. I also agree with your take that the glass is half full.
While many people have criticized TC39 for taking so long to get to releases like ES5 and now the Harmony features. I disagree. I think that taking time is a good thing. It has helped JavaScript turn into a more learned language. I look at what happened to Java... and I would hate for that to happen to JavaScript. I think that taking time has helped it.
Also, having never used CoffeeScript, I do recognize that it will help developers begin to release ES6 code sooner, by providing cross-platforming and backwards-compatability. I would love to begin using ES6 ASAP, but most of us can't even using ES5 yet. I think that CoffeeScript will serve to fill the years until ES6 is generally and reliably available.
Cheers on the post! Great job!
+1 for WebStorm, love it. I switched to it from Sublime, not because I dislike Sublime but because I had issues keeping all my Sublime plugins working. Plus, the refactoring support in JetBrains products is amazing.
I really like WebStorm, it’s the best JavaScript IDE I have seen, so far. But it still has a Java feel to it and I’m not sure one can ever completely eliminate that feel unless one programs the IDE in JavaScript (with the additional advantage of dog-fooding the tools). Plus, its shortcuts on Mac OS are terrible: Command-Up does not go to the beginning of the file, Command-W does not close the current tab, etc.
I agree with WebStorm not being perfect, but it is more aware of the language, which is why I prefer it to Sublime Text, at the moment.
My hope is that ES6 will become the new CoffeeScript. Then you wouldn’t even need to compile on modern browsers (during development).
What about CoffeeScript appeals the most to you? A lot can be done via libraries, static type checking and type guards (alas, post-ES.next).
A good IDE should be like a (graph) database of all the relationships and concepts in your program. For exploring source code, I’d want queries. Then current IDE GUIs can be understood as visual ways of creating queries and displaying results.
Consistency. The biggest JS pain. With CoffeeScript, I have one nice class definition. One nice way to iterate array. And I do not think where I should place my var keywords. At top of method? Everything? Even vars from for i =? So again, CoffeeScript is about consistency. And without C-like ; {} () mannerism, code is shorter and easier to read.
http://estejs.tumblr.com/post/29175863516/why-coffeescript
"A lot can be done via libraries..." I don't think so.
The only reliable tool for static type compilation is Google Closure. I used it before CoffeeScript, and now with CoffeeScript too. What else should I solve with library? Inconsistence can't be solved with zilions micro-framework :))
One example of library-like functionality that markedly improved JavaScript: Array.prototype.forEach.
- Class definition: Agreed. Coming up [1].
- Iterate an array: use Array.prototype.forEach().
- var: I agree that var is a mess. let will fix all of that. But I like explicit declarations, they prevent typos and bring clarity. For example, I’d rather that Python had something like let.
- Easier to read: I’m torn. I like both syntaxes. But I think CoffeeScript goes to far in allowing parentheses being omitted around function arguments.
[1] http://www.2ality.com/2012/07/esnext-classes.html
Array.prototype.forEach sucks, I really don't like it. CoffeeScript for in is 1) much readable 2) no need to define scope 3) is breakable
There is only one usecase for forEach.. when we have several different callback. In any other case, forEach is anti-pattern.
My observation about optional parentheses: surprisingly ingenious! You wanna know why?
Once you get used to do not write them, you are uncomfortable with them, and that's good thing.
I hate jQuery overchained code style:
$(el).getFoo().doBla(1,2,3).noEndYet().andAgain()...
It's hard to debug and test. It's simply wrong.
With CoffeeScript
foo = $(el).getFoo()
bla = foo.doBla 1, 2, 3
Do you see that code without chaining and zilions parentheses is more beautiful? One line should equal one operation. CoffeeScript parenthesesless syntax is soft power towards cleaner code.
ad explicit declarations. The truth is: you don't need it. Give me example, and I will refactor it. I bet refactored code will be more clean and less brittle.
I never feel the necessity for explicit declaration during writing https://github.com/Steida/este.
On the other hand I and hundreds of other people are using Haskell in industry (‘real world’) just fine.
I don’t doubt it, it’s a lovely language. My own Haskell project from 1999: http://www.pst.ifi.lmu.de/~rauschma/harry/
Are you happy with it when it comes to I/O and debugging? What do you see as its pros and cons?
Agreed. I hope ES6 is king in a bit. Not transpiling during development. It would be a build step. It would be nice.
I also have to back up steida on this - IDEs do have their place for me - mainly in clunky languages that require a lot of boilerplate like Java and C# .. where it's physically painful to write everything by hand..
But in the land of small, terse languages like JavaScript or Ruby they loose a lot of that.
They may do some good in navigating around, but since it's not really compiled and type checked most of the IDE searches are cases of a smarter grep - and one thing I know my VIM does superbly: search and edit stuff ..
IDEs may be a limiting factor for getting beginners from Java/C# into a language - people who actively rely on these tools. But for a experienced VIM user fluent in JavaScript no IDE will ever make him any faster..
Post a Comment