JavaScript as a Language

Posted: July 3rd, 2007

54 Comments (Show Comments)

1. Jonathan Snook (July 4, 2007 at 12:09 am)

   We shouldn’t forget, of course, that Microsoft has had JScript support in ASP for years as well as .NET, with (apparently) some ECMA4 constructs as well (likely to make it more compatible with developing under .NET).

   http://msdn2.microsoft.com/en-us/library/2z6exc9e(VS.80).aspx

2. Taras (July 4, 2007 at 4:04 am)

   I found javascript to be a good application-customization language for my DeHydra code checking tool. The new JS2 features are certainly going to make it the best language for the task(both speed & feature-wise).

3. Kroc Camen (July 4, 2007 at 5:31 am)

   I look forward to Tamarin. I’ve been writing a heavy UI in Prototype and Scriptaculous, and WebKit is 10x the fluidity of Gecko. The difference is staggering. Safari opens the popup instantaneously, whilst there’s a split second lag in Firefox.

4. Chris Zumbrunn (July 4, 2007 at 5:33 am)

   Jonathan, we could make the list of server-side environments that use Javascript a lot longer. Javascript has been used on the server-side in many products ever since Netscape used it in its server-side offerings. What makes Helma special, is that it is for “Javascript as a Language” what Django is for Python and what Rails is for Ruby. In fact, Helma probably was the first Rails-ish web framework, offering an agil development approach and code-less mapping of objects to database tables, long before there even was such a thing as Rails.

   At the time of Helma’s first release in 2001 the problem was that Javascript was deep in its dark age. Hardly anybody took Javascript seriously as a language. The manifestos for a Javascript enlightenment were already in place, though. David Flanagan released the fourth edition of his Rhino book, which cleanly separated the core Javascript language from the client-side Javascript and Douglas Crockford wrote his now famous “Javascript: The World’s Most Misunderstood Programming Language” web page, but not many noticed.

   Back then, I thought that Javascript was so much stuck in browser-centric preconceptions that we could never redefine what “Javascript” was perceived as and that we should switch to using the language’s original project name “Mocha” when talking about it outside the web browser. Later, the Ajax hype came along and proved that it is possible to redefine the way the language is perceived. Generally, Javascript is still seen as a client-side language, but I think we know now that this case change quickly :-)

5. Chris Zumbrunn (July 4, 2007 at 5:52 am)

   Actually, Helma goes back further than 2001: http://web.archive.org/web/20000829140639/http://helma.org/

   Boy does time fly. Back then, it used FESI as its Javascript engine, before it later changed to using Rhino.

6. Kirit (July 4, 2007 at 6:04 am)

   You may be interested in Mahlee. It’s a multi-threading API for JavaScript which is suitable for client or server. It uses CSP or futures so is very easy to use.

   http://www.kirit.com/Categories:/Mahlee%E2%84%A2

7. Jose Ortega (July 4, 2007 at 6:34 am)

   You can also develop desktop apps with AIR (formerly Apollo).

8. Clive Murray (July 4, 2007 at 7:08 am)

   It’s wonderful to not be in phase 3 any more. I tired of all the “JavaScript??? Pffft. Try a programming language!” style jibes pretty quickly.

9. Wanderlust (July 4, 2007 at 8:49 am)

   HD DVD also uses ECMAScript with HD DVD Script API to create Advanced Content.

10. Rupesh Gaandu Gupta (July 4, 2007 at 11:29 am)

    YOU GUYS SHOULD CHECK OUT THE SUN PHOBOS PROJECT/

11. Frederic Jean (July 4, 2007 at 12:18 pm)

    I would second looking at Phobos (without the caps though ;) ). It has a set of NetBeans plugins that makes it much easier to use. I’ll have to check Helma too now.

12. Robert Kaiser (July 4, 2007 at 2:24 pm)

    I guess I would be doing a lot more work with JS if I could replace PHP with it ;-)

    That is
    1) As a server-side, webserver-integrated (maybe JIT-compiled) language for dynamic creation of web content
    2) As a commandline scripting language

13. Joel (July 4, 2007 at 2:41 pm)

    You can use JS and Adobe AIR to create desktop applications. That is pretty sweet.

14. Doug L. (July 4, 2007 at 5:50 pm)

    Quite a few people are in phase 5 already: Javascript as a code generation target.

15. Anand Kumria (July 4, 2007 at 7:54 pm)

    Something else to check out is Samba 4.0 which allows you to manage it via javascript.
    It is still alpha-code, but very interesting none-the-less

16. Spocke (July 5, 2007 at 7:54 am)

    Regarding using JS as a server side language I found this thing it’s kind of a extension of JS to be used in the browser, Flash and on the server. Interesting concept but not standard since it is it’s own language. http://haxe.org/

17. Justin (July 5, 2007 at 8:35 am)

    I for one would rather much rather seen a language with a sane syntax move into the browser space (won’t happen). I’ll admit I’m not a fan of the language but it’s hard for me to understand this push to bring Javascript out of the browser when there are (in my opinion of course) MUCH more suitable (and pleasant) scripting languages available. I spend most of my day right now on the server side (in Python) and when I move into the browser space (JavaScript) it’s truly painful as I wade through the sea of curly-braces, semi-colons (put one there.. no not THERE!), unusual object syntax, framework incompatibilities, etc. In other words, the only time I use JavaScript is when I have no alternative and the concept of using javascript as a server side scripting languages sounds downright masochistic. Am I missing something?

18. James MacFarlane (July 5, 2007 at 8:54 am)

    Justin,

    I used to hate JS for the same reasons. Like any other language it’s just a matter of getting in the groove of the patterns.

    Now I love programming in JS, especially since the industry has embraced JSON and Ajax.

19. Justin (July 5, 2007 at 10:25 am)

    James,

    What about external libraries? Languages such as Python (and to an extent Ruby) have a vast number of stable, free, open source libraries (like reportlab or PIL) to handle pretty much any task you’d want to throw at them.

    I’m in no way trying to convince anyone that they’re wrong to use whatever tools they prefer. I just don’t see the reasoning here. A GUI that works for both the web and the desktop I can understand. Shoehorning JS onto the server seems like climbing a mountain “because it’s there”.

20. Justin (July 5, 2007 at 10:39 am)

    Upon further reading it appears that you can access Java packages though it’s done through methods that are not part of the ECMA standard. It kind of fits in with my feeling that using JavaScript for some purposes has the disadvantage of going against the languages original intention. But I’ve seen the language grow from the red-headed step-child of web development to a key part of modern web application design so who knows. I may end up writing database queries in JS after all (shudder).

21. Chad Burt (July 5, 2007 at 11:07 am)

    I’m certainly not one to say that javascript is a “bad” language. I like the syntax and appreciate its power. At the same time though, why bother? There’s already a rich selection of scripting languages such as python, ruby, etc with lots of external libraries available. Why make a javascript-based rails? What is there to gain, other than a more fragmented community?

22. Shadowfiend (July 5, 2007 at 11:07 am)

    If Javascript starts becoming popular, it will start getting libraries. Much like Ruby five years ago probably didn’t have a fraction of the libraries available for it now, but intense interest in the language made the number of libraries being built for it skyrocket. The early adopters are, I would argue, typically the ones skilled enough to also expand the library base of the language.

23. blackdog (July 5, 2007 at 11:10 am)

    Please take a look at haXe, http://www.haxe.org, developed by one guy, it puts the mega-corporations to shame, and answers the question “statically or dynamically” by providing optional typing with type inference. Check it out you won’t be sorry.

    Full dislosure: I’m about to release a JQuery inspired (thanks!) library for haxe.

    Cheers bd.

24. sreenu (July 5, 2007 at 11:10 am)

    hi this thing useful very good..

25. Chris Zumbrunn (July 5, 2007 at 11:10 am)

    Justin, because we are talking about using Javascript outside the web browser and the DOM, these restrictions and incompatibilities do not apply. For example, in Helma you can directly use any Java libraries, like you mentioned. There is probably no language that has a wider range of available libraries. To instantiate an object from a Java class in Helma you could simply use something like:

    var foo = new Packages.com.bar.util.Foo()

    http://helma.zumbrunn.net/intro/javapackages

    That’s not an explicit part of the ECMAscript language specification, but it doesn’t contradict it in any way. ECMAscript is intended to be integrated in host environments that make special objects like this available. The DOM in the web browser isn’t part of the ECMA standard either.

    On the server-side you are in control of the environment in which your application runs, which means you do not have the compatibility issues you are used to from the web browser. Also, you do not need to wait for new technology to be adapted by the user community. So, on the server-side you can always make use of the latest Javascript features. For example, you can use E4X because you would know that your server-side environment supports that.

    Another example is being able to extend the Object and Array prototypes without worrying about breaking for/in loops, like is currently the case on the client-side. That ability alone allows you to bend Javascript in the directions of your preferred coding style and makes it incredibly flexible.

    What you can’t change, of course, is the curly braces syntax. But I think the fact that it shares that syntax with the two big languages C and Java is ultimately Javascript’s big advantage that makes it a good companion in these environments.

26. robertj (July 5, 2007 at 12:05 pm)

    At the moment javascript is missing important tools for develop
    larger projects. I find it painful to create more than the
    simplest of web guis.

    http://yozzeff.blogspot.com/2006/05/me-afraid-of-javascript.html

27. Theo (July 5, 2007 at 12:46 pm)

    Let’s not forget ActionScript (which is compiled JavaScript running in Flash). With ActionScript 3.0 (JS 2.0) and Flex, JavaScript has absolutely reached the fourth phase.

28. Dustin Diaz (July 5, 2007 at 1:36 pm)

    I’m seeing JavaScript moving into a new phase where it’s eventually going to become serverside js of old (but not sucky) that netscape had done a while back. Leaving out the DOM API, we still have something really nice that can do a lot of really cool things.

29. Joe Crawford (July 5, 2007 at 1:48 pm)

    Justin —

    I don’t think anyone’s making a claim that JavaScript will supplant Python or Ruby or any of the other scripting languages, just that it is a language, by virtue of being probably the most ubiquitous (in browsers) programming language ever, with serious momentum.

    Those of you not sure what the hubbub about JavaScropt is about can get up to speed by watching Douglas Crockford (a guru at Yahoo!) on YUI Theater. Of particular note is his talk “JavaScript: The Good Stuff.” His history of the DOM and history of JavaScript are also excellent.

30. Jamie (July 5, 2007 at 3:34 pm)

    I share some of the concerns over JavaScript as a server-side language but like someone else pointed out, theres been JavaScript (or JScript) support in ASP since the beginning of time.

    As a developer i often have to climb a wall when moving between server-side and client-side coding. If my head were in JavaScript land all day long i can’t help thinking my life would be a bazillion times easier.

31. neimad (July 5, 2007 at 6:23 pm)

    If you are a die-hard JavaScript coder from the start, you wouldnt need to use Python or PHP or other such languages on the server-side. JavaScript for front-end and back-end tasks works great. I’ve been using it for both tasks for years and years. I know other languages, but rarely use anything but JavaScript – except when i need assembly language speed for embedded devices.
    There is no greater satisfaction as a web programmer than being able to copy-and-paste JavaScript code written for the browser into the back-end and not have to tweak much if anything at all. I’m equally good at coding back-end as I am front-end (as long as I stick with JavaScript), and my development cycles reflect that.

    Compiled JScript using .NET Forms is also very cool. It is much easier to do than most people might think. I’ve been coding windows applications with JScript for a little while now and it is really fantastic to have the entire .NET world available to a JavaScript programmer.

    JavaScript isn’t going away. It is available on the back-end of many platforms, and is universal as a front-end web programming language. Some things may be easier to do in other languages, but for someone who is a front-end coder who wants to get into back-end programming, having to go through VBscript or PHP or Python is going to slow you down a lot. Sticking with JavaScript has allowed me to devote all my time to mastering it. I know so many VB coders who are clueless on the front-end, and it hurts their products when they try to do both.

32. Lance Fisher (July 5, 2007 at 6:42 pm)

    JavaScript as a server-side language is definately interesting. I could see it becoming confusing at times. Right now, when I look at some code I know immediately that it is running on the server based on the language. However, wouldn’t it be cool to directly pass objects back and forth from client to server using JSON?

33. William Beh (July 5, 2007 at 7:49 pm)

    Lotus Notes client have been supporting the use of Javascript for quite some time. It complement well with the use of @Formula and LotusScript language.

34. Paul Sanders (July 5, 2007 at 9:01 pm)

    The most crazy usage of JavaScript I’ve ever seen is a programmable SMTP gateway (eWall) from Server Side Solutions group. They use JavaScript to program SMTP event handlers such like OnCommand and OnReply and navigate/modify through message parts like through DOM.

35. mike (July 6, 2007 at 3:50 am)

    As one who has done some fairly heavy Javascript work on both front end (www.calcresult.com) and on back end (Hyperwave) I can say that I would never consider putting JS into a server-side system. Not because the language is unsuitable, but because it can, and will, be abused so heavily.

36. Stephan Beal (July 6, 2007 at 4:26 am)

    See http://SpiderApe.sourceforge.net
    That’s a C++ framework built on the SpiderMonkey engine, for embedding SpiderMonkey in C++ applications. Unfortunately, JS (or at least the SpiderMonkey implementation) makes certain features of “real languages” difficult to implement, a notable example being JS-side threads (which are next to impossible to implement on top of SpiderApe).
    While i hate and despise and will never like Python, i must admit that it stole a market which could have belonged to JavaScript if the community had had a decently-organized/publicized JS implementation to take ahold of and run with (SpiderMonkey works well but can be a real bitch to work with).

37. Stephan Beal (July 6, 2007 at 4:27 am)

    Sorry, correction to the last comment:

    “which are next to impossible to implement on top of SpiderApe”

    Should have said “… on top of SpiderMonkey” (and, by extension, SpiderApe).

38. Chris Zumbrunn (July 6, 2007 at 5:05 am)

    @mike: how do you mean that it what be “abused”? That developers would not follow best practices and coding conventions?

    @Stephan Beal: This is probably a SpiderMonkey specifc problem. With Helma you can make asynchronous invocations using the app.invokeAsync() method:

    http://helma.zumbrunn.net/reference/app.html#invokeAsync

    Rhino also offers the ability to directly leverage java.lang.Thread and java.lang.Runnable to run Javascript multi-threaded:

    new java.lang.Thread(new java.lang.Runnable() {
    run: function() {
    while (notYetDone) {
    doSomething();
    java.lang.Thread.yield();
    }
    }
    }).start();

39. Christian Decker (July 6, 2007 at 5:54 am)

    I’ve been using Cocoon on a regular basis for the last few years and at first the idea to use JavaScript on top of a Java Framework to do the business logic seemed a bit far fetched/hard, but I shortly afterwards became aware that JavaScript is about as a perfect match for this task as you can find. The flexibility of the language is amazing, and being able to create new object-class on the fly has proven often to be just the solution to a problem I had.

40. Chris Smith (July 6, 2007 at 11:25 am)

    Don’t be bullied by those, who for no reason other than personal insecurity (or financial interest), deride JavaScript as a language.

    Compared to Java, C# (and the CLR/.net stuff), and XML for that matter – JS is a lightweight and very useful technology. That’s enough to earn it a great amount of praise. It’s not ubiquitous in business like Java or the MS technolgies, but these are business decisions driven by large sales organizations and have little to do with ‘choosing the best technology’.

    Java is on its way down as a technology, I suspect Linux as well.
    They become so overloaded with size and complexity, that they lose their usefulness, weighed down in their development by an ever growing bureaucracy. The cost to the developer, that person’s time in being able to do anything useful, being subjugated to other interests.

    It’s encouraging to see new releases, SMALLER than the previous, and simplified, as is happening with some of the JS frameworks. There is a backlash, which has already begun against cumbersome frameworks and my hope is that JS doesn’t go the path that Java and Linux appear to be traveling.

41. Kingsley (July 6, 2007 at 12:32 pm)

    I am hopeful of the prospects of Java as a server side language, but wonder why cutting out the DOM is considered such a great thing. The DOM is a known and well understood model for constructing a web page. I wish I could instantiate a document, add nodes to it, use XPath/CSS selectors to get at them and generally jQuery the hell out of apps on the server side. Is that so bad?

42. jim d (July 6, 2007 at 12:46 pm)

    I’ve used javascript on the client side for a few months now using the javascript shell that is bundled with Rhino. I use it as a replacement for writing batch scripts. I love the fact that you get can easily modify your code and re-run, yet also easily hook into the JDK framework.

43. Nilesh Patel (July 7, 2007 at 1:53 pm)

    John,
    After you talk is done, would you posting any notes or videos? for guest to checkout? would be interested in hear or reading about it.

    thanks,
    Nilesh

44. alek (July 9, 2007 at 10:15 am)

    One of the most interesting non-browser uses of JavaScript I have come across was in Adobe Photoshop; which eventually grew to other products http://partners.adobe.com/public/developer/scripting/index.html and of course was a key part of their SVG plugin. A small but active community has grown up around it http://ps-scripts.com/bb/index.php

45. Mike Abraham (July 9, 2007 at 3:17 pm)

    It’s a floor wax, and a dessert topping.

46. beecaver (July 10, 2007 at 10:16 am)

    Some folks mentioned AIR, but note that Adobe’s ubiquitous Flash and its Flex platform also use ActionScript, and extension of ECMAscript, the standardized base for JavaScript. Adobe is participating in Tamarin as an open-source basis for an optimized Flash VM.

47. Jonathan dos Santos (July 10, 2007 at 10:52 am)

    Javascript divorcing from concept of web, or people marrying it?

48. Ankur (July 11, 2007 at 8:59 pm)

    Javascript is supported in Quartz compositions. It’s also possible to use Javascript to access classes in the Cocoa Objective-C framework on the Mac.

    Still, a lot of people whose primary language is not Javascript often object to it or don’t appreciate it enough.

49. Scott Wickham (July 15, 2007 at 8:54 pm)

    Another Server side use of JavaScript came from the POW Firefox plug in that make Firefox into a web server.

    https://addons.mozilla.org/en-US/firefox/addon/3002

    There is a growing wiki of information at

    http://davidkellogg.com/wiki/Main_Page

    and a small but growing community

    http://groups.google.com/group/firefoxpow

    In addition to POW as a firefox plug in Dave Kellog has rebuilt it in XULRunner. We have a windows and Mac installer. And even a combiened version that runs off a USB Pen drive that you can take with you from machine to machine.

    Every improvement in firefox or Javascript improves POW, so Sqlite databases are included and you can use E4X on the server and client side.

    POWUSB

    PowUSB combines both the Mac and Windows XULrunner versions into one install. Just unzip into the root directory of your USB pen drive and you can click on the Pow_Mac or Pow_Win and it will load Pow. Use the options to make your USB root Pow’s root and you are up an running on Mac or PC. I have also included my sqlite manager in the install. Enjoy.

    You can download it a http://www.scottwickham.com/powusb.zip

    Anyway keep up the good work. Only the power of Mozilla platform makes this possible.

50. Lori (July 18, 2007 at 11:28 am)

    I tried to promote JavaScript as a programming language years ago (at conferences, where I was mostly looked at quizzically by the organizers: “you mean browser scripting?”), when we added a JS interpreter to Dreamweaver 1.0. We (the development team) had this idea that because web developers “already knew JavaScript”, they’d have an easy time extending the product using JS. However, the programming skills required to write anything more than the most basic object were quite beyond what was normal/average for web developers at the time. It’s pretty exciting, 10 years later, to see JavaScript re-emerge as a programming language. I’m not sure how many developers want to write extensions to Dreamweaver, but it’s cool that so many more *could* now than in the late 90s.

51. Brendan Eich (July 24, 2007 at 6:42 pm)

    Stephan Beal: SpiderMonkey can be compiled JS_THREADSAFE. This support has existed for many years (it predates the founding of mozilla.org in 1998).

    In fact tellme.com, recently acquired by Microsoft, uses SpiderMonkey in its massively threaded VXML-based AVR service (which, last I heard, powers AT&T’s 1-800-555-1212 / local 411 automated voice response). The implementation allows shared objects while guaranteeing memory safety, but SpiderMonkey itself doesn’t provide Thread objects or explicit mandatory synchronization primitives. Others can and have added such library objects and methods.

    I’m on record as opposing shared memory threads and explicit mutual exclusion primitives being reflected into the standard language (see my blog), but the JS engine can and should be able to run multi-threaded — precisely to exploit parallel hardware.

    The likely way forward in the short run for exploiting hardware parallelism in JS is shared nothing worker threads (see for example Google Gears). Longer term, we’re looking at transactional memory as well as message-passing shared nothing.

    /be

52. August Tu (August 28, 2007 at 10:15 am)

    I think as you say – Javascript will grow up to a normal language for program.
    Can I translate this archive to Chinese, so can let more people use chinese language to learn it?

53. [email protected] (September 29, 2007 at 12:59 am)

    ztuhclypr dnhvpzobf afncki jmuolit igwfpl bykojvqa uxhnikpm

54. amix (November 1, 2007 at 5:06 am)

    I do not understand the focus on Javascript as a web-language (now at the server and not on the browser).

    Javascript is a wonderful language for Powerusers (users doing actually some serious work with their computers, regarding them as tools).

    The text-editor I use (http://www.zeusedit.com) can be scripted by the ActiveScript languages, including JScript. The same is valid for the IRC client I use (http://klient.com), which has an extremley powerful API, which can be programmed by JScript. DesktopSidebar (http://www.desktopsidebar.com) can be scripted (albeit somewhat limited) by ActiveScript (including JScript). SerioousSamurize! can have meters being implemented in ActiveScript. Most major Microsoft applications can be scripted that way. Microsoft allows for creation of COM objects in J(ava)script. PDF can be scripted with Javascript, practically all major Adobe programs, KDE seems to go into that direction (Kommand and KROSS).

    If you have a look at the Web-Mashups, which still are pretty much of a toy only, imagine, what can be done with real IPC scripting and macroing. Something like REXX allowed for on OS/2 and AmigaOS. Applications, which you can completely remote-control by scripts. This means, that every application may become like a shared function library (or module) to an application you write yourself in that scripting language. It becomes even more interesting, if you envision a common, standardized and well defined API of “Doing Things” like: “Send Email”, “Download FTP”, “Spider Web-Page”, “Process Image”, “Get Contact, “Get Bookmark” and so on. The user would install the application of choice, which would conect to this well defined API of user/desktop-scripting.

    I have done similare things ten years ago on AmigaOS, not as professional (there was no such API, I tried to implement it myself, but switched host in 2001). You practically get Desktop Mashups. Applications communicating with each other. The possibilities are endless. It could be explosive.

    I enjoy Javascript and never understood, why people did not realize its object-orientiveness. I mean, what do you think, if you see something like this, “window.onload” ecxept OOP ? ;-)

    I fear, that, while levelling the power, JS2 will take away JS from the powerusers and make it a thing for “real programmers” only. Learning-curve to high, language too professional like. I would not want too much more being added. Add namespaces, imports, filesystem- and other system-access (managed), certain enhancements to the OOP stuff and some very clever pattern parsing (like in REXX for example) and I’d be mostly satisfied.

Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.