Javascript will be the Next Big Language

I’m on JavaScript kick lately. Or rather, I have been rediscovering it ever since I read the series of Steve Yegge’s blog posts on JS and Rhino and his predictions for the next big language. I really think he is right – JS will be the next big thing that will trump Ruby from it’s pedestal or at least become its viable competitor as the next big dynamic scripting behemoth. Why? I think a better question is: why not? It almost seems like this language is destined for greatness.

For one, JavaScript or rather ECMAScript is really a kick-ass language if you look at it objectively. When I say JavaScript most people automatically think about the client-side, browser dependent, inconsistent scripting language which only works half of the time. But this is not really the fault of the language but inconsistent implementation of the DOM model across different browsers.

Internally the language is really consistent, flexible, readable and fun to use. Not only does it have most of the cool features that are all the rage now (ducktyping, closures, variadic functions, prototypes, metaprogramming end etc..) but reads a lot like C. The syntax is full of the familiar and lovely brackets and semicolons that we all know and love (or hate) and all the control sequences and language constructs follow the familiar C patterns. Coding in JavaScript is really a lot like coding in Java only 5 times less verbose which is a good thing.

And when it comes to shuffling around HTML or XML data there is no other language that is both so good at it, and so well documented. We have been using it for that purpose decades now and nothing else compares. No other language can be used int the online so effectively and seamlessly.

Also, Javascrip has something that neither Python nor Ruby possess – a real spec. So it is really a good language – a Language with capital L. It is just burdened with a bad stigma of being a browser specific toy language.

This stigma is slowly dissipating as the Web 2.0 craze is raging on. I don’t care who you are right now – if you are doing any web development right now, you have to deal with Javascript whether you want it or not. You can avoid it, you can claim you are server side guy but if you want to be competitive right now your web app needs to use AJAX and if it is, then Javascript is becoming a big internal part of your code base. You can hide behind a framework, and have it generate AJAX code for you the way RoR does, but sooner or later you will have to do something complex and will end up hacking on js files. Whether you love it or hate it – you will be exposed to it at some point.

So your code is now roughly half Javascript and Half something else which is a bit messy, but that’s Web 2.0 for you. Does it have to be that way though? Of course not. You don’t need a dedicated client side language ad another dedicated server side language. You could really do all your scripting on both sides with Javascript. Yes, Server Side Javascript is not a joke or some pipe dream – it is reality. Believe it or not, but there is a lot of development going on in this area – there are tons of projects out there which use JS on the server side.

These projects range from very simple to very complex full featured solutions. For example, mod_js is an Apache module loosely based on Perl’s CGI.pm which implements ECMAScript on the server side. It is astonishingly simple, and compact but also very immature project.

If you want something more robust and mature there is Jaxer – a self contained Java based server which supports server side scripting in Javascript. The whole idea behind this environment is unifying your code base. With Jaxer you can use the very same language to query the database, dynamically rearrange the HTML output, and make asynchronous calls back to the server. Added bonus is that it is bundled with the very popular Aptana IDE (aka. the Eclipse for web designers) which means it is already near ubiquitous.

If you are allergic to Eclipse and it’s forks and you like NetBeans then Phobos is probably what you will want to sink your teeth into. It uses Glassfish server and uses Javascript as it’s default server side language. Same concept, different approach. The project seems to be mature, well supported and have a big community.

Want more? Theres Helma which is a Rails like framework which leverages server side Javascript and Rhino. The whole thing runs in the JVM and uses Jetty as the default, self contained web server – but you can also put it behind Apache or IIS if you want. How come you can go wrong with a combination like that? You get a MVC framework with a self contained server and set of useful tools and utilities that only requires you to have a basic JVM installed. You get to script it with the dynamic and flexible language that requires no compilation, and no SDK. You get the entirety of the Java API at your disposal courtesy of Rhino. Not only that, but you can simply drop in your custom precompiled Java libraries and classes and seamlessly integrate them into your project.

But there is more – recently I spotted another interesting project called Junction. Like Helma it is a Rails like MVC framework that uses Rhino but in addition, it also has a built in support for Google Gears. This means that apps built on the Junction framework get to benefit from the offline persistence features offered by the Google technology.

There is all this development going on out there. It’s not very visible yet – most of it is somewhat behind the scenes. But it’s like that distant rumbling before the storm. You know something big is coming. Just look around.

You want to develop rich client interfaces? There’s XUL and Adobe Air for you – both using Javascript at their core.

You want dynamic web UI framework? There is JQuery, Prototype, Dojo, Google Web Toolkit and YUI just to name few.

Want to use Java API? Use Rhino. Want to tap into the richness of Microsoft CLR and interact with the rest of .NET ecosystem? Theres JScript.NET. You want to do some native scripting on MacOS? There is Javascript OSA.

You want to add oflline persistence to your web applications? You need Google Gears which is also using Javascript.

The language is everywhere. Everything that is new, that is hot and that relates to the web is at least touching or benefiting from it. Every developer will see it, and work with or alongside it sooner or later. It’s ubiquitous.

The pieces are slowly falling in place and setting up the stage for the upcoming explosion. It’s no longer question of whether we will reach that critical mass, but when will it happen. We have the tools, we have the technology, we have the hook and the need (unifying the client and server side under one language) – now we just need to wait for the hype. And for that, we need branding. Steve Yegge talked about this during his Ted talk – we need to re-brand the language to make it more sexy. Everyone thingks that Javascript is a toy language, and ECMA sounds like a some sort of acne prescription so we need a new, cool name. We also have a good reason for re branding – the upcoming release of Javascrip2 standard which brings about many new features to the language such as classes, interfaces, namespaces, packages, destructuring assignments, structs, type declarations and more.

It is a bucket load of new features so why not start fresh, with a new sexy name and identity. I mean look at AJAX – the acronym really means “using the asynchronous calls in Javascript” but if you say it like that, people immediately fall asleep and run away. But AJAX is cool and sexy. Javascript can be to – and I predict it will be, sooner or later.

[tags]javascript, ecmascript, rhino, scripting, helma, jaxer, junction, sever side javascript, mod_js[/tags]

This entry was posted in Uncategorized. Bookmark the permalink.



41 Responses to Javascript will be the Next Big Language

  1. confused UNITED STATES Mozilla Firefox Windows says:

    your f’n crazy

    Reply  |  Quote
  2. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux Terminalist says:

    Maybe I am, but I think I’m in good company considering a lot of influential people out there (Steve Yegge for one) think the same way. :)

    Reply  |  Quote
  3. Tim Stewart UNITED STATES Mozilla Firefox Windows says:

    Thanks for the article. Do you think that JavaScript’s name (i.e. the fact that the word script is in there) might hold it back from being more fully adopted?

    Reply  |  Quote
  4. James H UNITED STATES Mozilla Firefox Windows says:

    I’ve moved towards haXe, niche as it may be, because it has the Javascript syntax and compiles down to JS (and to other platforms – Flash is fully supported, and PHP support is now in an early alpha state), but also adds optional ML-like static typing and a more substantial base library. If you’re looking for a full-interoperability solution haXe is ideal as it really delivers on “write-once run-anywhere” promises.

    Reply  |  Quote
  5. Justin D-Z UNITED STATES Mozilla Firefox Windows says:

    I’ve been twittering and blogging about this recently. If you add in CouchDB (for example), you define your database views in javascript. This gives you the possibility of javascript for the web server, framework, templating, data definition, client-side scripting and lightweight desktop apps. That’s one language straight through, and an interesting language nonetheless.

    My only concern with something like Rhino is that I don’t want to use Java to build libraries or use the Java libraries particularly. I’d rather build libraries in javascript too. I also really like the gem/plugin approach. Is that an issue because of the JVM or just something that has yet to be built for javascript?

    Reply  |  Quote
  6. tim UNITED STATES Mozilla Firefox Mac OS says:

    The reason ECMAscript *needs* a spec is that there are so many different implementations of it, and even so it’s not hard to come up with something that works fine in one but won’t even parse in another. In my experience CPython/Jython and Ruby/JRuby are just as portable (“almost the same but you still gotta test”).

    In a world where MS Office has an ECMA standard, it’s hard to take that as a serious argument. ;-)

    Oh, and since you’ve been using an 11-year-old language for “decades”, I figure you must be using the latest ECMAscript-2031, which I admit is a pretty cool language, but for the rest of us it’s still 23 years away. :-)

    Reply  |  Quote
  7. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux Terminalist says:

    [quote comment=”8853″]Thanks for the article. Do you think that JavaScript’s name (i.e. the fact that the word script is in there) might hold it back from being more fully adopted?[/quote]

    Yes. Actually, I think Java in JavaScript is more harmful at this point – but both parts of the name are less than perfect. When I say JavaScript people react in few predictable ways. They either think it is part of Java, that it is a toy browser based language or they tell me “your f’n crazy” :P

    So I think it would be nice to call JavaScript2 something else to:

    a. let people know that it is not Java, and it doesn’t use Java syntax
    b. it is not a “client side scripting” language
    c. make people think “server side and applications” when they hear it
    d. make it sexy so that it is easy to hype and evangelize

    [quote post=”2406″]I’ve moved towards haXe, niche as it may be, because it has the Javascript syntax and compiles down to JS[/quote]

    I never used haXe – I will need to check it out. Thanks for the link.

    Reply  |  Quote
  8. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux Terminalist says:

    [quote post=”2406″]My only concern with something like Rhino is that I don’t want to use Java to build libraries or use the Java libraries particularly. I’d rather build libraries in javascript too. [/quote]

    You can build libraries in JavaScript – they are going to be simple JS files though. :)

    The nice thing about Rhino is that you can actually write something in JavaScript and then compile it into a .class and plug into a Java project. So it works both ways. :)

    [quote post=”2406″]In my experience CPython/Jython and Ruby/JRuby are just as portable (”almost the same but you still gotta test”).[/quote]

    Btw, I never meant to detract from usability or portability of Ruby and Python. They are mighty fine languages, and you are right – a language does not *need* a spec. But having one is always a plus.

    Reply  |  Quote
  9. Interesting article. For sure it would be nice to have the same language on both sides, on all sides actually.

    Yet… JavaScript sucks.
    But I use it.
    Ruby rules. But I cannot use it.

    I hope that “compiled” JavaScript 2.0 with static typing comes real soon… so that it becomes the output of some better language compiler!

    Reply  |  Quote
  10. Luke Maciak UNITED STATES Mozilla Firefox Windows Terminalist says:

    [quote post=”2406″]I hope that “compiled” JavaScript 2.0 with static typing comes real soon… so that it becomes the output of some better language compiler![/quote]

    Actually, static typing is overrated. First you need to declare types. Then you either have to manually cast stuff, or rely on some boxing and un-boxing logic. A strong typed but dynamic language is inherently more polymorphic, with much less typing, and much less stuff going behind the scenes.

    As for compiled – you can easily compile js files into Java bytecode that will run on the JVM. This is supposedly what Google is doing for a lot of their stuff – they use js because of it’s nice features, ducktyping and readability and then compile their production code for speed.

    Reply  |  Quote
  11. Peter Cooper UNITED KINGDOM Mozilla Firefox Mac OS says:

    You’re not f’in crazy IMHO :) I’m a Rubyist and have held the same opinion for a few months now. I’m one of those fellow crazies who thinks ECMAScript derivatives will be the de-facto programming languages in the 2010s.

    Reply  |  Quote
  12. Joe Strickler UNITED STATES Safari Mac OS says:

    I was going to read your article, but there are two painfully obvious mistakes in the first and third paragraph.

    If you’re not willing to read your own work once, I’m not going to take the time to read it either.

    You may have a good message, but you can’t insult your readers by dishing out this crap.

    Reply  |  Quote
  13. bullbuster UNITED STATES Internet Explorer Windows says:

    Dude, you’re smoking crack. Serverside javascript has been around since the 90s in the form Microsoft ASP 3.0. I’m growing weary of all these young punks who are coming around thinking they know something.

    Reply  |  Quote
  14. Luke Maciak UNITED STATES Mozilla Firefox Windows Terminalist says:

    Damn! What’s with the negativity today. Did I get linked from some fun place like Digg or Reddit?

    [quote post=”2406″]I was going to read your article, but there are two painfully obvious mistakes in the first and third paragraph.[/quote]

    Dully noted and fixed. I did read it back, and re-wrote it like 3 times, which is where the mistakes creped in I think.

    Anyways, since I’m a nice guy I will file your comment under my “constructive criticism” mental folder . :P

    [quote comment=”8864″]Dude, you’re smoking crack. Serverside javascript has been around since the 90s in the form Microsoft ASP 3.0. I’m growing weary of all these young punks who are coming around thinking they know something.[/quote]

    Yes, we had this technology for a while now. How many people were using it on the server side back in the early 90’s? Most people mainly used the language for form validation and simple hover animations throughout the 90’s.

    It’s the same thing as AJAX. We had the functionality to make asynchronous calls since forever, but no one has figured out how to use them to build dynamic and rich interfaces. This didn’t really happen till recently and people only started going apeshit for it when the technique was re branded as AJAX.

    Same thing happened to Ruby – it was a small new language that didn’t really have much traction at the begging and only after Rails exploded all over the internet it became this popular.

    Reply  |  Quote
  15. stuart updegrave UNITED STATES Mozilla Firefox Windows says:

    A couple of timeline nitpicks:

    As ‘tim’ already pointed out, it’s not likely that anyone has been using Javascript in any of its flavors for decades, since it first appeared in a beta of Netscape 2.0, in December 95. 12-1/2 years, not ‘decades’.

    “How many people were using it on the server side back in the early 90’s?”

    None. The first server-side implementation wasn’t until 1996 (Netscape Enterprise Server) followed by support by Microsoft with ASP 2.0 (shipped with IIS 4.0) in 1997.

    FWIW, I was one of the folks using server-side Javascript in the *late* 90s, working on Microsoft’s Site Builder Network in ’97/’98, or ’98/’99.

    Reply  |  Quote
  16. Luke Maciak UNITED STATES Mozilla Firefox Windows Terminalist says:

    [quote post=”2406″]As ‘tim’ already pointed out, it’s not likely that anyone has been using Javascript in any of its flavors for decades, since it first appeared in a beta of Netscape 2.0, in December 95. 12-1/2 years, not ‘decades’.[/quote]

    Yeah, I know – I used “decades” more as a figure of speech. What I really meant was “for over 9000 years” :P

    [quote post=”2406″]FWIW, I was one of the folks using server-side Javascript in the *late* 90s, working on Microsoft’s Site Builder Network in ‘97/’98, or ‘98/’99.[/quote]

    Awesome! But again, I don’t believe it was as big back then as for example Ruby is right now, was it? That’s really what I meant. I believe JavaScript will explode in the future and will be huge.

    Reply  |  Quote
  17. One of the issues with JavaScript is the standard library that comes with it. It sucks. There is not even a method to get a copy of something. i.e. no dup(), no clone(). The thing was and still is half backed.

    Worse: The caching mechanism of scripts is so bad that one has to optimize the size of the javascript code transmitted to the client, down to bytes, welcome to the heighties. This makes it rather difficult to grow an after the facts standard library, doesn’t it.

    Not talking about all the pseudo “security” limitations, pure paranoia.

    The result is Google Gears and co, where one has to “enhance” the crappy client with another artificial level of indirection. Make things even more artificial and complicated for the developer.

    Yet, overall, I guess you are right about JavaScript being something very significant. Some call it the “Lingua Franca of the Internet”. http://virteal.com/JavaScript

    Hopefully that situation will change when JavaScript will be fast enough to code a VM using it. HotJava and similar Ruby to JavaScript solution will then emerge.

    Reply  |  Quote
  18. Sbep THE FORMER YUGOSLAV REPUBLIC OF MACEDONIA Mozilla Firefox Windows says:

    Well, lets get constructive here. When you say JS needs branding i sense you mean a new name. But it must distinguish itself from the rest out there and not associate with:

    – caffeinated beverages – to get away from Java
    – precious stones and crystals – no rubies or emeralds
    – music notation – no notes or music keys to get away from the .Net craze to “sharpenate” everything
    – snakes or lizards – pythons or anacondas…
    – blazing monkeys or flaming foxes – to move away from Mozilla (maybe no animals what so ever)
    – cleaning products – like AJAX
    – maybe no acronyms – get away from pimply sounding ECMA

    Uh… when i put it this way maybe there is nothing left to name it. We will end up with a NoName(TM) language that will solve all all programmers problems in the world.

    Reply  |  Quote
  19. prashant UNITED KINGDOM Internet Explorer Windows says:

    Hey,

    I even like javascript a lot and predict that it can go firing in future.

    Thanks
    Prashant

    Reply  |  Quote
  20. Adam Kahtava CANADA Safari Windows says:

    I agree JS could be the next mainstream programming language, and even if it’s not, JS is permeating the software development field. So regardless it pays to understand the language. One thing I’m really enjoying is all the web-service to JSON serializers, most of my applications are transitioning from the server-side to the client-side using the SOA model.

    @JeanHuguesRobert
    Turning JS into a staticly typed language is probably a bad idea. Staticly typed languages are overrated.

    How well do you really know JavaScript?

    Could you post a link to Steve Yegge’s Talk?

    Reply  |  Quote
  21. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux Terminalist says:

    [quote post=”2406″]One of the issues with JavaScript is the standard library that comes with it. It sucks. There is not even a method to get a copy of something. i.e. no dup(), no clone(). The thing was and still is half backed.[/quote]

    I think that JavaScript 2 spec will include support for classes and class based inheritance (not just prototype objects) which means clone function will find itself into the core library out of necessity. :) It will also have interfaces, type annotations, namespaces, packages, scope operators and bunch of other cool stuff. It will be a whole new language and a vast improvement over what we have now.

    @Sbep – LOL!

    Reply  |  Quote
  22. To be honest, I have some serious doubts about this prediction. To start with, have you ever tried to write a serious library in Javascript? As you said, it’s reminiscent of C, and that includes how you have to structure your APIs. The language is object-oriented…sort-of, and it’s functional…sort-of. It’s dynamically typed, but it also has type coercion (maybe). The whole thing might be spec’d out, but from the perspective of a developer trying to *use* the language (not build an interpreter), it can be a real challenge trying to keep all of its behavioral quirks straight.

    All of the language “features” aside though, I suppose there’s nothing really *preventing* JS from becoming the dominant language except for developer perception. You said it yourself, people think of Javascript as an elaborate joke by Netscape. It doesn’t matter if that’s true anymore, because the notion has taken hold. And if you need an example of how devastating developer perception can be to a language, consider how weak Java’s adoption has been on the desktop. It’s far more powerful, full-featured and (often) easier to work with than most popular desktop languages, but the popular perception is that it is dog-slow (something which hasn’t been true for years).

    Maybe Javascript deserves to be the “next big thing” (though I doubt it), but whether it deserves it or not, developers will never accept it.

    Reply  |  Quote
  23. vd PORTUGAL Mozilla Firefox Mac OS says:

    The language is everywhere.

    Hold on buster! Where’s javascript on the 13 billion mobile devices ? Oh right!

    Reply  |  Quote
  24. jambarama UNITED STATES Opera Windows Terminalist says:

    Javascript is fine for basic scripting, but in my experience to do anything substantive it has to be very heavy and glued to about half a dozen other “technologies.” I think stuff like GWT, WPF, & ZK are doing well – people have realized the lousy performance (among other negatives) javascript offers.

    I have several large complaints about my experience with js. If I misrepresent js, sorry, please feel free to correct me, this is just from my experience.

    Js is OO gone retarded. Everything is an object – a “variable” can be anything: a number, a function, a pointer, a string, a location, anything except definitely a number or string. Especially on variables, js is retarded.

    Another pet peeve of mine with js is tables. Maybe I’m doing them wrong, but AFAIK to create the table you have to create a text object for each bloody cell. To do this you have to create the object and then associate it with the cell. Then when you refer to the frame, it has a .Text property which you can set. Seriously this is the best way of creating tables??

    My opinion of it isn’t all bad. I’d agree with many of the points you’ve made. The amount of tools out there for it, make if quite flexibile (although lets keep it light on the frameworks, lest we end up with java-esque problems). I also generally like the sytax. I don’t want js to go away, I just don’t want it used for purposes it is fundamentally ill-suited for.

    I’d love to be proven wrong on my complaints. And a lot of this may just be because I use js so infrequently, and with time I’d see the logic/wisdom behind the facade of idiocy, but I doubt it.

    Reply  |  Quote
  25. Adam Kahtava CANADA Mozilla Firefox Windows says:

    These comments really attest to the poor perception of JS in the dev community.

    @jambarama Classical OO and Static Typing could be for sadomasochists – while these models are useful they’re also broken, there has to be something better. Dynamically typing and prototypical inheritance are lighter weight and more expressive. Even MSFT .NET is moving towards being more dynamic and more expressive – more like Ruby, Python, and JavaScript.

    Reply  |  Quote
  26. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux Terminalist says:

    [quote post=”2406″]Js is OO gone retarded. Everything is an object – a “variable” can be anything: a number, a function, a pointer, a string, a location, anything except definitely a number or string. Especially on variables, js is retarded.[/quote]

    But the same can be said about Java – everything is a child of Object class, except the primitives, but you usually end up wrapping them into a descendant of Object class anyway. This is what polymorphism is all about.

    But if you like more structure the JavaScript 2 will include more traditional class and inheritance system and optional type references. It’s not going to be statically typed though because that would just be silly.

    [quote post=”2406″]Classical OO and Static Typing could be for sadomasochists – while these models are useful they’re also broken, there has to be something better. Dynamically typing and prototypical inheritance are lighter weight and more expressive. Even MSFT .NET is moving towards being more dynamic and more expressive – more like Ruby, Python, and JavaScript.[/quote]

    Precisely. I used to be firm believer in static typing, but then I got over it and I absolutely love not having to write all that boilerplate every time.

    Let’s face it – when we use statically typed language, we “cheat” the compiler every time we want to use polymorphism, or even store bunch of different typed values in the same array. We have to wrap them into containers, then cast them into proper types, or use generics notation and etc… We are really emulating what a dynamically typed language does by default.

    Reply  |  Quote
  27. To be clear, polymorphism is a fundamental part of *any* decent type system, static or otherwise. If you consider Java as an example, I can think of three different forms of polymorphism without cheating the compiler at all.

    I think what you’re referring to when you say “polymorphism” is actually what most people refer to when they say “dynamic typing”. Dynamic type systems are no more inherantly polymorphic than static type systems, with the exception of their adoption of implicit structural types (duck typing). However, there are statically typed languages which have a type system every bit as polymorphic as any dynamic language (think Scala). In fact, statically typed languages have a huge flexibility advantage over dynamic languages in the area of implicit type coercion (again, consider Scala as a good example).

    I’m not saying that static typing is inherently superior to dynamic, but to claim that it is less polymorphic or even less expressive is simply ignorant.

    Reply  |  Quote
  28. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux Terminalist says:

    Actually, I agree – static typing is probably less expensive performance wise, since the compiler knows what to expect and optimizes ahead of time. But not always.

    I think I expressed myself wrong – polymorphic behaviors simply take less typing in dynamically typed languages – at least on average. So it’s not “more polymorphic” – just more expressive.

    Reply  |  Quote
  29. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux Terminalist says:

    Also, to everyone knocking JS for performance – things work differently on the server side. Compile your .js file into .class bytecode with Rhino and you end up with the same optimization JIT compiled performance as Java.

    @Daniel – let me try to figure out how to say it in another way. Static typing is really just like heaping additional meta data on top of your code. Not exactly, but roughly that’s what it translates to.

    You know, I’ll just refer you back to Steve Yegge for a much better explanation on the whole “static typing ain’t that great” philosophy.

    Reply  |  Quote
  30. Static typing has 2 benefits: Speed, Speed.

    I don’t buy the “early error detection” security that some people try to sell. Asserts and test suite are the right way to manage software code quality.

    Regarding speed, static typing is necessary. Sometimes, in some languages, the compiler can infer the type, maybe even at run time, using sophisticated just in time compiling, this is rare. This is not available in JavaScript. More often, in most languages, it is up to the developer to specify the possible types.

    If one were to write a Virtual Machine, one would use static types, for speed. Sometimes, too often, speed matters. That is why static types in JavaScript 2.0 is something needed.

    Reply  |  Quote
  31. Tyler Larson UNITED STATES Mozilla Firefox Mac OS says:

    JavaScript in its current form has major problems but the next version is shaping up to be something much different. It will be years before we can really use it in a browser but it will be very close to what ActionScript 3 is now.

    The best thing that JavaScript2 has going for it is that there is a large community of people including all of the major companies figuring it all out as a group now rather then what is happening with Ruby were everything is being broken up because of different ideas. (CRuby, JRuby, IronRuby, Rubinius, and I think there is another one ) JavaScript should have a common base for all platforms as soon as they figure it all out.

    Also HaXe is a very cool project but not a good choice for anyone looking for the future development language, you may be able to compile down HaXe code to other things but you are always limited to what that language can do, programming in HaXe is just confusing and disconnected. But still cool.

    Reply  |  Quote
  32. Luke Maciak UNITED STATES Mozilla Firefox Windows Terminalist says:

    [quote post=”2406″]Static typing has 2 benefits: Speed, Speed.

    I don’t buy the “early error detection” security that some people try to sell. Asserts and test suite are the right way to manage software code quality.[/quote]

    Well said. Still, sometimes sacrificing some speed for increased readability, and expressibility of your code is not that bad.

    This argument is a little bit like the argument about garbage collection. Any language that uses it, pays a performance penalty but most people (sans die hard C zealots) agree that it is a good thing in most circumstances.

    When we are talking about web applications, the overhead of dynamically typed language is negligible if you consider the real bottlenecks such as database queries and other remote calls.

    [quote post=”2406″]Also HaXe is a very cool project but not a good choice for anyone looking for the future development language, you may be able to compile down HaXe code to other things but you are always limited to what that language can do, programming in HaXe is just confusing and disconnected. But still cool.[/quote]

    Until today I never heard about HaXe. It’s a coll idea, but I don’t really buy into the whole meta-language thing. It seems like an unnecessary layer of abstraction if you ask me – and a potentially leaky one. I have to take a closer look at it to see if my gut feeling is right though. It might be halfway decent after all.

    Reply  |  Quote
  33. Binny V A INDIA Mozilla Firefox Linux says:

    JavaScript rules in the browser scripting area – it is already the ‘big language’ there.

    But will it get a hold in the other fields(Server side programming, shell scripting, etc)? I hope it will – but I am not very optimistic about it.

    Reply  |  Quote
  34. davey UNITED STATES Mozilla Firefox Windows says:

    Just in case you haven’t noticed, Javascript is already the most deployed language there is. pretty much every web request is from a device supporting js, (braindead mobile stuff aside), no other language has the reach of js.

    The amount of developers that are familiar with it way exceeds even java, this is why js as an end to end platform facility it is a very compelling argument. (developers, developers, developers…)

    but to get there lots of stuff needs to be happen. libs, performance etc. It is happening though, client js, server js, couchDB, is the most coherent stack available today, a stack where you can learn a single language to it’s fullest and use that knowledge in whatever part of the app you are working on.

    I’m hopeful it will work out, but so many factors are in play that you can’t make a rational prediction of the outcome.

    If nothing else fun times ahead.

    Reply  |  Quote
  35. Mike CANADA Mozilla Firefox Windows says:

    JavaScript continues to blow my mind every day – it’s like play-dough for the web. Server-side JavaScript? That’s a frightening thought that I’m now going to have to look into deeper – thanks for the article!

    Reply  |  Quote
  36. Ed UNITED KINGDOM Mozilla Firefox Windows says:

    You bet. Look at http://www.effectgenerator.com for an example.

    You forgot that Flash is now written in Javascript, which is pretty important!

    Reply  |  Quote
  37. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux Terminalist says:

    [quote comment=”8916″]You bet. Look at http://www.effectgenerator.com for an example.

    You forgot that Flash is now written in Javascript, which is pretty important![/quote]

    Wow, that is pretty impressive. :)

    Reply  |  Quote
  38. Derrick UNITED STATES Mozilla Firefox Windows says:

    I’m surprised you didn’t mention tamarin “a high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification.” http://www.mozilla.org/projects/tamarin/ .

    It’s basically the next rhino .

    It’s used by flash player, as you’ve sort of already mentioned for the AVM2 (ActionScript VM2).

    ActionScript 3 is basically the closest thing to JavaScript 2.0 right now.

    Reply  |  Quote
  39. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux Terminalist says:

    Good point Derrick! It should be up there on my list, but I totally missed it. Thanks for bringing this up.

    Reply  |  Quote
  40. Pingback: Terminally Incoherent » Blog Archive » Stages in Life of a Web Developer UNITED STATES WordPress

  41. Volomike UNITED STATES Mozilla Firefox Ubuntu Linux says:

    I agree wtih this post. I think every PHP developer should be mindful to watch out for progress from Apache and Mozilla development teams for when they implement an Apache mod that loads a super-fast Javascript intepreter that supports add-ons to be easily written in C. Once that gets to fullspeed, you’ll start to see the advantages of using one single language to make your website — Javascript on the server, and Javascript on the client.

    And when that happens, you’ll want to watch out for what happens on the job project and freelancer sites. Will we start to see an uptick for requests for this platform? I think so, yes, and it might start to ramp up in 2011, if not sooner.

    You might want to keep an eye on this chart.

    Reply  |  Quote

Leave a Reply

Your email address will not be published. Required fields are marked *