From a panel discussion at Lang.NEXT on cloud and web programming this afternoon.
Erik Meijer: Are you saying you cannot write large programs in JavaScript?
Anders Hejlsberg: No, you can write large programs in JavaScript. You just can’t maintain them.
Update: The video of the panel discussion has been posted here.
Update update: Looks like the links to Lang.NEXT and the videos are dead.
Funny, I’ve seen fans of pure functional programming say the same thing of stateful languages. Meijer and Hejlsberg are pillars of the static language world. I’m not sure I would take them at face value on judgments against dynamic languages.
I say this as a long-time fan of static languages, but I think that the challenges of Javascript maintainability have little to do with the language, and almost everything to do with programmer diligence. Yes, static languages force you into diligence. You can’t be lazy in the same ways you can in dynamic languages. But there are plenty of ways to be lazy in static languages too, and I think we’ve all seen just how unmaintainable static typed code can be.
But–and this is key–there’s nothing stopping one from applying the same principles of clean code and SOLID design to Javascript that we are accustomed to in C#. They just look a little different. I think we’ll see that as the Javascript development community continues to mature, and particularly as TDD’ers and BDD’ers migrate in.
Yeesh! I’d better stop using TiddlyWiki right now. It could explode, or something.
I’ve worked with a rather large mostly Lua (very similar to JS, though a bit less…quirky) codebase (Adobe Lightroom) for over 6 years now. While the dynamic nature of Lua changes the kinds of maintenance challenges one faces, I wouldn’t say it’s harder to maintain/update than a comparably sized codebase in a static language (never mind that I suspect the same functionality in such a language would likely be larger in terms of total code volume).
I sometimes miss the sophisticated IDEs and tooling to which I grew accustomed to in my Java days (especially the profilers, but that’s another story), but when I go fire up Eclipse to do some Java, there’s plenty of things I miss from working in Lua as well.
Static languages do impose a certain structure on things, but I have yet to see a language which really constrains the kinds of behaviors that make for unmaintainable code. For that, you need diligence on the part of the writer and/or diligence on the part of readers (team members) exerting peer pressure.
We are working hard to solve this. The JSC project allows one to compile a C# client-server web application to JavaScript. Get in touch to learn more!
JSC Installation
JSC WebGL Spider Model
Probably the best example of a large scale javascript application is the embedable google maps api, which has roughly half a dozen developers working full time on it. They make heavy use of OO techniques, and use a “build” system that handles dependencies properly. Based off talks I’ve had with one of these developers, it sounded like it was absolutely maintainable as long as the design was kept modular using OO techniques.
The context of the above quote was a fast-paced and often funny discussion. Catch the video when it comes out. It was entertaining and informative.
Anders was using hyperbole. Yes, it is humanly possible to maintain a large JavaScript program. It has been done. But that doesn’t mean it is easy. It may indeed be beyond the abilities of many programmers, and those who can pull it off will find it more difficult than maintaining a large program written in languages designed for writing large programs.
I think he has a point. For the average two-bit developer, the most developers are in that category, maintaining a large Javascript system would be much more of a challenge. They need the static language to guide them.
@John:
> It may indeed be beyond the abilities of many programmers,
So, just like building a maintainable *large* application?
The quote you posted is just a demonstrably false cheap shot.
@John:
> It may indeed be beyond the abilities of many programmers,
So, just like building a maintainable application in a static language?
The quote you posted is just a demonstrably false cheap shot.
That’s what I thought. Which is why I implemented a huge project with Google’s Web Toolkit, cross compiling Java code to JavaScript. Best. Decision. Ever.
I maintain large JavaScript programs for artificial intelligence (AI) in English and in Russian by updating them simultaneously in Forth.
Sometimes I don’t know why people that should know better make such claims. You can write a horrible, unmaintainable mess in C# as well and it’s one of the better languages I have worked with so far.
Eclipse -> Call Hierarchy
’nuff said
I think tiddly-wiki is assembled and written in ruby. After which the application runs as javascript.
david: See my earlier comment. Anders’ remark was humorous hyperbole. But there is a serious point to it: it is easier to maintain large programs in languages that were designed for maintaining large programs.
John: I think are close when you say, “it is easier to maintain large programs in languages that were designed for maintaining large programs.” Although I don’t think that has anything to do wether its a dynamic or static language, which is where I think people think the argument is. It has more to do with the structure a language gives the developer to manage large code bases.
To start, if you think about something as simple (and old) as #include (c), import (python), use/require (perl), the fact that JS has nothing of the kind natively is pretty much the end of the argument. That there is 20 or more different frameworks that provide a solution to this isn’t evidence in support of Javascript’s robustness, its pretty clear evidence to the contrary.
I agree. The primary weaknesses of JavaScript have nothing to do with the static/dynamic debate.
All “large” programs are difficult to write and maintain. I’ve found it easier to modify large programs written in functional JS patterns than those written in say, C#, simply because I don’t have to seek through and edit so many files when I make a change.
With discipline, large programs can be written and maintained in any language. A major advantage of static languages lays with their ability to limit damage inflicted by mediocre programmers.
Speaking from experience working on one of the largest ASP.NET codebases (2 mio loc), and working on one of the largest javascript / node.js codebase (~ 400K loc, ex. external libs), plus having the joy to do the largest refactor on them that the codebases ever had: The truth is, it’s both hard, very hard to build large, scaling, maintainable applications, but I believe that with a good experienced team you can achieve the same level of maintainability on both platforms. The difference lays in:
1. .NET will force you in one direction, with a standard stack of modules, javascript won’t. That means that it’s possible to choose the wrong stack more easily, ending up with an unmaintainable application.
2. Tooling helps, and the level of tooling for .NET is better than javascript at the moment. However, times are changing, static code analysis and a general better level of tooling are coming to javascript as well.
3. The learning curve for building large applications in javascript or any dynamic language is way steeper. If you break a contract in .NET, ‘compiler error’. These things can be solved in javascript, but you will need time and patience to get accustomed to these.
4. Writing unit tests on an existing codebase in .NET is impossible without a shitton of refactoring out dependencies. Javascript has it way easier, you can just mock out dependencies at runtime w/o changing the code of the class under test, resulting in a better code coverage in less time.
5. Javascript requires a lot less code.
Anyway, in general, building large JS apps is not impossible, but you’ll need the right stack. We built an open source dependency/plugin/isolation library that solves quite some of the architectural problems you’ll run into when building a large, large application on node.js. It’s basically all lessons learned in 1,5 years time combined in a package. https://github.com/c9/architect
Regardless of several comments here, we still believe that the static typing brings some order and robustness in your projects, a dynamic language (Javascript in particular) lacks. Of course you can impose yourselves numerous rules when developing in Javascript in order to keep to complexity down.
We developed ST-JS a Java to Javascript generator (http://www.st-js.org). The main purpose was to generate a Javascript code that is as close as possible to the Java course.
In the begininng the Java code we wrote for our projects was quite similar to our regular Javascript projects. But gradually we observed that the developers, freed of the burden to keep the complexity down, dared to create much more complex and powerful code. It was (still is) a funny experience!
I too believed it wasn’t possible to maintain large scale products with Javascript.. until I really had to do couple of large scale projects with JS.
With the learnings I had, I thought of creating a reference architecture for maintainable modular JS programming for large scale product development.
http://boilerplatejs.org
I’m the author of BoilerplateJS that address critical concerns such as:
– Structuring the solution
– JS dependency management
– Loosely coupled product modules
– Routing, History, Back/Forward buttons
– Localization
– JS minification and obfyscation
– UI components, templates, css, code-behind
– Unit Trsting
– Documentation Generation
– Inter-module event communication
It is not a library, but the startup code with samples if anyone is interested to learn from my experiences.