The most important language of yesterday was C. Of today, still C. Of tomorrow, Go... hahaha no, the answer is still C.
If you really wanted to determine 'most important', think about what software you'd be left with if all software and dependencies written in a language was taken away.
Take away JS and a bunch of webapps don't run. Take away C and you have no OS, no web servers, no languages whose leading implementations don't bootstrap themselves, no TomToms telling you how to get to JSconf, and so on.
I do understand the renewed hype behind Javascript, but to enshrine it as most important -- talk about hyperbole and a lack of perspective.
PS: That V8 engine you'd be relying on for your JS -- it's not written in Javascript either.
> If you really wanted to determine 'most important', think about what software you'd be left with if all software and dependencies written in a language was taken away.
That's one definition of "important". However, now that we have the OS's and webservers -- and are building _on_ them, what's the most important? Your point is like saying nuts and bolts are most important, for if you take them away the car will fall apart ;-)
I think Steve Yegge said this kind of thing a few years ago - namely that javascript is one of the most important programming languages today. I'm not saying that this invalidates the point, just that it was probably fairly apparent when he said it and, in my opinion, pretty obvious today.
Also, he mentions "And while we’re at it, maybe use it for desktop applications too?" which I think is interesting because Mozilla already has built a framework to do this kind of thing, with xulrunner. It's not based on V8 but newer builds do incorporate Mozilla's version of a javascript JIT, tracemonkey.
I seem to remember Yegge's drift was on the next version of JS, which diverges somewhat from what we have here -- the AS3-like one with optional strict typing, formalised classes, and modules. (Having tried AS3, it seemed like a modernised Java: rather office-world utilitarian.) Of course, that new version didn't quite happen . . . or, I don't know, I haven't looked recently . . .
There's absolutely no question that javascript is going to be the single most important langugage for GUI app development, if it isn't already.
However, I'm still not persuaded that it's a compelling server-side programming language. Javascript wins in the browser because it has no competition, but there are already several mature, well-established server-side programming stacks in langauges with fewer warts.
I've recently been using it as part of CouchDB. It's really not a bad language. Some of the constructs are a little cumbersome, but it does just about everything you'd want a language at that level to do.
With the V8 engine it really is pretty speedy, and you have the advantage of using the same language for your UI and your server-side processing.
As a language, I feel like Javascript decided to repeat half the mistakes Perl made and to tack on a few unique ones of its own. Supposedly the latest version, ECMAScript 3, improves on javascript a lot, but in the end I would pick Python or Ruby over javascript any day. The section about javascript at http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m... is funny because it is true!
It's too bad that Javascript has become the assembly of the web. I've found GWT to be a terribly leaky abstraction. I've watched as projects like HotRuby stalled and faded. And I've seen projects like the scala version of j2js grapple with performance issues such as inefficient method call overhead in current javascript implementations. I really believe that javascript at this point is holding back progress on the web.
I really hope something like google's NACL succeeds where all the other RIA frameworks have failed. To do so, it is going to have to integrate with the browser much better than applets, flash, etc, but if it succeeds it could allow for a multi-language renaissance on the client that would benefit everyone and force javascript to actually compete with the rest of the PL world.
I love Python the language and all the great libraries that come with it. The reason I chose JavaScript for server side has a lot to do with V8. Also, if you follow best practices for coding styles and use JSLint, javascript is very powerful.
Sure. I have no doubt that it's capable. But that's not good enough. You have to be significantly better than an entrenched technology to displace it and the only thing I think server-side JS really has in its favor is that people will presumably already know Javascript and right now that just doesn't seem like enough of an advantage.
> There's absolutely no question that javascript is going to be the single most important langugage for GUI app development
It might or might not be, but this is far overstated. In terms of rich graphical GUI apps, there is much much more that has been done with either AS3 or Objective C at this point.
I think Javascript optimists vastly underestimate the distance it would need to go to replace either or both of the above.
I have been working on a project that required clients be implemented in both Obj-C and JavaScript. They are functionally equivalent. The code base of the Javascript version is close to 20 times smaller and was coded about twice as fast. I much prefer Javascript for UI work.
I still haven't seen anything in AS3 or Objective C that compares at all to the state of the art in native C++ interfaces (Photoshop, Cubase, Autocad etc), but that's not the 85% that counts. Javascript/HTML5 clearly has the momentum. If there's not 10x as much code being written five years from now in JS as Obj-C/AS3 I'll be very surprised.
Are you really calling photoshop and autocad state of the art in user interfaces? While I certainly appreciate the power and features offered by both apps, the actual UI is really nothing to write home about. Sure they get the job done and generally stay out of your way (once you've gotten the hang of them), but there is really nothing cutting edge of even slightly interesting about them.
The DOM and built in libraries are of course terrible, but I really am talking about the language. Mainly it needs an object system where different programmers' versions of objects can interact with each other easily and seamlessly in the same way. It also suffers badly from not having a real dictionary type. (Objects are slow, and checking for hasOwnProperty() is a pain in case you import something from someone who thought it was brilliant to extend the Object prototype.)
The magic 'this' parameter is a complete mess. Global scope by default for variables and no block scope is terrible, as is changing scope of variables from global to local if I later add a "var" version later on in the function. (Sure we should avoid global variables but they shouldn't be so easy and encouraged, without a real namespace system.)
Newlines acting like semicolons bites people a lot that I've seen as well. I hate the inconsistency in the object literal syntax. I need to quote the left side of them anyway, e.g. {"interface":"my-interface"} will break otherwise, so why not make it consistent and allow a variable, so I can pass {key: value} into a function requiring a dictionary? I also hate the inconsistency of keywords. Why can I redefine "undefined" and "NaN", but not "interface" or "super"?
Some of these are warts but not having an agreed on object system is a show stopper for general use, imo. Who rolls their own prototype system in Java? Nobody. Who rolls their own imitation of classical objects in JS? Most people.
> Mainly it needs an object system where different programmers' versions of objects can interact with each other easily and seamlessly in the same way.
It has one, as long as you don't need to inherit from other people's objects. But inheritance is a pretty poor way to compose code in most OO languages, especially single-inheritance ones like JavaScript and Java.
> Who rolls their own prototype system in Java? Nobody. Who rolls their own imitation of classical objects in JS? Most people.
Well, a few people. Mostly people familiar with class-based programming languages, which you are surely aware is a minority of the JS-programming population. One of the first things I did in Python was roll my own prototype system, actually.
I really think you should organize your points better. There are some really serious flaws in there (the need for hasOwnProperty() and global-by-default) but you've mixed them indiscriminately with minor annoyances (keyword inconsistency, the absence of classes, no block scope).
I've been using JS on the server for over a year and let me tell you, it rocks. It is easy, really easy to do stuff with it. You should give it a try to understand how easy it is.
- Get data from SQL backends, easy.
- Templates, easy.
- MVC, easy.
- Curl, Ajax, easy.
- JSON, XML, easy.
- Files, sockets, easy.
You name it, I assure you it is easier than any other language you've used before.
I say, it is just a matter of ONE year to finally mature the most interesting projects out there, Node.JS and V8CGI
If you want to get your feet wet, go grab V8CGI and play with it, really easy. If you need to play with the geekiest stuff, get Node.JS then.
I guarantee you, you'll never look back. But please, give it a try before judging it.
I don't recommend rhino, ringo, or narwhal, just because I don't like to run on top of java. You may try spidermonkey or flusspferd if you like C++ more.
Whatever your flavor, give it a try, then come back and share your experiences.
- Global variables by default, which means you will have "var" sprinkled everywhere.
- Brain-dead binding.
function Constructor() {
this.foo = 'bar';
var that = this;
window.setTimeout(function() {
alert(that.foo);
}, 1);
}
- You can call a function with less arguments than specified, meaning you potentially have to make sure each argument is not "undefined" .
- Somehow JS isn't weakly typed when it comes to switch statements.
a = 5;
b = '5';
if( a == b )
alert("Equal");
switch (a) {
case b:
alert("This never shows");
}
I am fairly certain that JS popularity is mostly in part due to its monopoly on the web. I'm sure there are more experienced JS users who can point out more flaws.
Sorry pal, if you write spaghetti code JS will bite you in the butt, but I've been coding for 20 years and I'm used to declare everything before using it and to be very careful when choosing names for my stuff and never do silly equalities.
Yes, and I'm sure you never have memory management problems in C and are an above average driver. But for the mere mortals who occupy most development positions, having behavior silently and radically change when you forget a "var" is not a good thing.
Nowhere did I complain about needing to declare things before using it. Having variables be global by default is really poor design.
And about silly equalities, it will inevitably happen once your programs get bigger, and you become frustrated with a bug that has been suppressed through multiple function calls because Brendon Eich thought weak typing was a good idea.
Upvoted the article because I think it's time to bet the farm on web client javascript development, rather than pursuing individual native client development (unless you have a valid marketing reason to go after one or more native clients for your app).
Too bad he never mentions spreadsheets. They are one of the most widespread (and overlooked) programming tool. And you are in for serious money, if you can improve them (and sell your improvement).
The whole article was pretty much from the point-of-view of a web-based application. Maybe he is assuming web-based applications are the most important ones.
These are my thoughts about the subject:
- Python and Ruby seem interesting. But JavaScript is going to be there nevertheless. Furthermore, it seems like 80% of the functionality in a RIA is going to happen in JavaScript anyway.
- JavaScript in client and server. I haven't done, My guess is that with JavaScript the talent of the developer to organize a big code base becomes critical.
- Java and GWT. I've tried this. It works nicely. Strong typing and a great IDE with Eclipse. Same language in the server and in the client.
- Scala and (Scala compiled into JavaScript? This could be nice. We just need somebody really smart to make it happen.
I kept thinking about the last part. Scala is a really nice language. The GWT route was to create a Java compiler to generate JavaScript. Doing the same for Scala seems like a huge effort. But what about this option? It is a little bit crazy though.
What if you use Scala to create a DSL to create JavaScript RIAs? The DSL can be the framework that will give structure to the RIA. Then you use JavaScript to fill in the blanks.
This post comes at a very interesting time. I'm a non-developer. I did graduate with a computing science degree, but really struggled getting to grips with programming and software development, so when i left uni i never created any of my own apps. I did retain some simple software development principles knowledge however.
But recently, i've been very keen to get involved in helping developers on my team improve the user experience of our apps, which is why i started looking into cappuccino.
Atlas and Cappuccino, I have to say are great as frameworks, but only for people with Macs.
So, since then i've been heavily looking into jQuery and found it to be great for helping me create good user experiences, and with the addition of AJAX things tend to get very interesting.
I'm in no position to comment on what i think to future is since im so new to development, but from where im standing and certainly for someone that is just entering the fore, i'm someone that has been through these exact set of questions in the last few weeks, and came to a very similar conclusion through my own trial and error.
You should really try NOLOH (http://www.noloh.com). I'm not just saying that because I'm one of the co-founders, but because we've found it to be the easiest way to create sophisticated websites, and WebApps easily.
Every year we get a batch of interns from high schools and colleges with no real programming experience, but can start writing full applications without any training whatsoever.
As part of the application process we require they write a TicTacToe application in our free hosted sandboxes and 9/10 times the applicant has no issue and replies with a link to their app. We don't guide them, train them, or instruct them in any way beforehand.
Watch our recent presentation from Confoo and see for yourself, http://vimeo.com/10106797. It really is that easy.
I've used NOLOH on a dozen projects, some very large a few modest and a few experimental and small. As someone who has a deep background in OO programming and design and who came to NOLOH with a strong distaste for languages with a C-like syntax (but still a JavaScript fan; go figure), I was not prepared either to enjoy or to appreciate NOLOH as much as I have come to do. It's the first tool I reach for when building Web-based software these days.
I'm not affiliated with NOLOH,but I am a fan, I know its founder through my work with his technology, and I'm always happy to chat about it with interested people.
I don't understand the negative feelings towards proprietary web frameworks. We offer a product that solves a problem. We've been working at it for 6 years, have invested hundreds of thousands of dollars into R&D, and have numerous free options for non-commercial projects, including free educational, non-profit, developer, and open source project licenses. Compared to our competitors we're leaps and bounds ahead of them technologically, and we undercut them on price significantly.
Really, what more can we do? Do you not use a tool because there's a company behind it providing support, up to date documentation, and other resources? We even have a clause that says if anything should happen to us, all the source is opened.
It's unsettling that many developers who charge for their own services and products let out a sigh when other developers decide to charge for their services and products.
jQuery is a good place to start. Getting into frameworks before you have some fundamental understanding of programming can make the learning curve a bit too steep.
jQuery is shallow enough that you can get a ton of work done with it, but still understandable enough that you can dive into it's source and fidget your way through it.
It took 6 paragraphs to get to the word JavaScript. JavaScript is here to stay and its adoption for server apps is on the rise and will be used in some cases where yesterday ruby or python would have been used. That's it in a nutshell. No sense in trying to tack on superlatives like "most important".
JavaScript is here to stay because Netscape threw it in the browser and somehow the browser wars didn't screw it up enough to make it problematic as cross-browser html & css. So its the only game in town for web browsers and once you get used to its warts, it does the job.
javascript is clearly the most popular and widely used programming language in history. c/c with classes has the most software built on top of it, putting them at the most important languages on opposite sides of the software stack.
what would be interesting is a back of the envelop calculation on # lines of js vs c executed globally per minute. id guss c probably wins due to frequency of execution.
Considering the fact that every line of js you execute is run in a VM that is implemented in c/c-with-classes I am guessing this will not really be much of a contest... :)
And on an OS mostly/entirely written in C. For most software out there I'd imagine C was used somewhere in that stack. The same can't be said about JavaScript.
That said, I bet JavaScript use will increase and C will shrink, relatively speaking.
If you really wanted to determine 'most important', think about what software you'd be left with if all software and dependencies written in a language was taken away.
Take away JS and a bunch of webapps don't run. Take away C and you have no OS, no web servers, no languages whose leading implementations don't bootstrap themselves, no TomToms telling you how to get to JSconf, and so on.
I do understand the renewed hype behind Javascript, but to enshrine it as most important -- talk about hyperbole and a lack of perspective.
PS: That V8 engine you'd be relying on for your JS -- it's not written in Javascript either.