Guest post by Fatal Exception’s Neil McAllister sees recent experiments enabling a resurgence for JavaScript on the server, one likely to dent Java’s role in the data center. ‘Today, projects such as CommonJS and Node.js are extending JavaScript even further, allowing it to take on Java’s traditional role in the data center. In a fascinating role reversal, JavaScript is becoming the versatile, powerful, all-purpose language for the Web, while Java risks becoming a kind of modern-day Cobol,” McAllister writes. And though such experiments have a ways to go, the benefits of JavaScript as a server-side language are clear and striking.
Java’s threat is not JavaScript, it’s Oracle and the big stink they are kicking up. People will avoid the language and new projects will begin to be made in JS and Java will eventually obsolete over the next decade; it will of course matter on where Oracle, and the community, take Java.
The inescapable truth is that client-side, Java is a complete failure. Developers would rather fight with a half-implemented language in half-implemented browsers doing all sorts of insane backflips (like GWT) *just* to save having to serve an <applet> to users.
And running the same code client side as server is a huuuuge boon which is really enticing to users.
Atwood’s Law could not possibly be more poignant. In the race to get everything running in a browser, the server too will pick up the ports too. Expect a flood of JS libraries for everything from encryption to video editing.
Well, there certainly needs to be a flood of libraries because currently JS has almost nothing.
Where exactly did the “Java” come from in JavaScript? Isn’t it technically “ECMAScript”? Sure, there are syntactic similarities, but the same could be said for C and PHP…
Not raging on technicalities here, I’m simply curious about the historical context.
It was simply a marketing move between Netscape and Sun.
IIRC Sun made a deal with Netscape (the “inventor” of JavaScript back in the day) to cross-license the “Java” trademark, since back then Java was marketed as the new hotness and they wanted some of that to rub off on them. (IIRC this was also part of a larger deal whereby various products were developed and sold jointly by Sun and Netscape under the moniker iPlanet, all of which IIRC is now completely owned by Oracle.) The fact that the syntax has a lot in common is just a bit of trivia that reduces the absurdity factor without actually eliminating it.
“JavaScript” is a valid Oracle trademark, no joke. They really do own the name and could protect it if they so want to.
The story is long and boring.
Netscape wanted a scripting language for its browser. At the time netscape also had a good relationship with Sun and Java was the new industry buzzword. (Netscape was working on rewriting Navigator in Java at the time, if I recall correctly.) Originally Javascript was called StarScript, and before that had some codenames that I now forget. Netscape, or perhaps Sun, wanted a scripting language to bridge the gap between embedded Java applets in the browser and the rest of the page. So, the nominal purpose of Javascript was to “script” Java applets. Plus, you got all kinds of automatic buzz! Netscape got a deal from Sun wherein it could use the “Java” in the name, since they were buddies at the time, and so began the most confusing marketing mistake in language history (so much worse than Go).
Microsoft didn’t have a deal with Sun for use of the Javascript name, so they called their similar scripting language JScript. I say “similar” out of kindness but in the beginning they were a lot less similar than you’d expect.
Eventually Netscape submitted Javascript to a standards group, in part to counter Microsoft’s incompatible implementation which was serving to fracture browser scripting (Microsoft, remember, wanted you to write embedded vbscript!) and the standardized version was released as ECMAScript, a name so uncatchy it was guaranteed to be ignored by everybody.
In practice, today, everyone calls it Javascript but only Mozilla officially is allowed to call its interpreter Javascript. Everyone else makes ECMAScript-compatible interpreters which are called a lot of different things that everybody ignores.
Somebody else can chime in with the actually-correct netscape/sun/java/script stuff, but that’s the gist.
Not so boring to me, I guess. Maybe I’m just a boring person. ^_~
And, why do you think that developers would avoid Java ? Because Oracle prevents Google from developing their own VM ? Because of some open source principles ? Who cares ? JDK is free for download, many additions and development tools, too. Java is stable secure and easy to deploy. There are alternative (compliant) JDK’s like IBM JDK, Apache Harmony, Iced Tea…..
There are loads of high quality client side GUI applications written in Swing and SWT.
How many applications have you ever sold to an enterprise customer ? I think it is somewhere around zero, right. Do you imagine that one can come with bunch of open source packages and start to build them with gcc on customers production server ? Forget it, normal people don’t even have C/C++ compiler on production machine for security reasons. And what about Windows servers ? Are they supposed to run Visual Studio on production server ?
JS needs standard way of deployment on major HTTP servers, at least one like PHP, which comes packaged and prebuilt for Linux, Mac and Windows, Apache and IIS. Something that IT department of the customers company might install and deploy with confidence, and without possible interference with other applications and services on the production server.
Until those conditions are met, JS is toy for hobbyists. Or, maybe, for sort of things like yet another Wiki engine for nonprofits, who will invite you to the party, instead of paying you money. On such parties, you might meet someone and have sex, that’s why such projects are called “sexy projects”.
I don’t see js threatening Java here.
It’s mostly competing with Django, RoR, PHP and various newfangled fad things (scala, clojure…).
Web server programming is a sort of wild west where everything goes and codebases are pretty small. Trend hoppers have jumped away from Java ages ago, and the ones that remain in Java are not likely to be interested in js – they have big teams (with continuous turnover) and deem static typing and “rigor” of the solution more important than agility. A huge js program sounds like a nightmare; even gmail is implemented in Java and translated to js with GWT.
Agreed. That’s why I use Script# myself (like GWT but for c# instead of java)
The main problem with javascript is that at least 90% of people who think they know javascript really know very little about it. They churn out vast amounts of totally crap code, then complain that its crap. Even in otherwise really great shops, for some reason, javascript is done really poorly.
I’d agree to that. For years I thought it was terrible, and complained to no end about it. Then I actually looked into the language itself. Its pretty interesting when done correctly. In my defense, the true nature of the language was really well hidden. I couldn’t find a decent book on the language itself that didn’t spend 90% of its time talking about the DOM.
The rhino book is very good.
Good js style still doesn’t change the fact that it’s a dynamically typed language, which by nature gives you lots of rope to hang yourself.
I’m a fan of dynamically typed languages, but not for large/complex projects that are likely to see lots of refactoring.
Honestly, I think that is a cop out. I work on a rails project that has about 180 models or so, and a really high level of complexity. What you need is a good team, and good practices. There are loads of the same sorts of IDEs that java has (rubymine for example, by jetbrains, really isn’t missing much) that will handle refactoring in the same way.
That being said, I am a vim guy, so refactoring for me usually means a combination of vim, grep, and sed
I have been there for about 6 months, and really don’t see any sorts of bugs that wouldn’t have been there if we were all on java. The benefits on the other hand are enormous when it comes to productivity.
I think it all comes down to the developers. If you have people on your team that you wouldn’t trust with a dynamic language, then its probably a bad idea. Good developers and a commitment to tdd, and it really isn’t that scary.
I’m sure you know as well as everybody else that it’s impossible to have the same kind of refactoring in a dynamic languages, due to the fact that less information is encoded directly in the source code.
Refactoring is not just an ide feature – it’s as much about making a change, compiling and seeing what you have to change all around the place.
Not all projects require this kind of rigor – actually, I think most server side web applications are quite simple (mostly encoding state in database), and hence suitable for quick hacks like RoR.
So whats the difference between that and making a change, and run your tests to see what you need to change? Other then that tests will catch way more issues then compiling will?
I think the difference is pretty obvious. In one case, you are forced to break the tests in order to “find out” what you need to change. In the other case, there’s a good chance you won’t have to break anything.
Um, that is exactly what automated tests are meant to do. break when something changes and causes regressions. Out of curiousity, what do you think tests are for?
…whoosh…
I am saying that there are fewer regressions when carrying out an automatic refactoring of statically typed code, because the IDE knows exactly how to modify every reference and method call for every reference to an object of a given type. With dynamically typed languages on the other hand, the tools cannot carry out automatic refactoring, at least not for dynamically typed object references.
Now you could say, “well, just use best practice and always type your variables” but that’s essentially admitting that dynamic languages’ primary feature is more or less useless.
Edited 2010-09-12 03:49 UTC
Ok, so what I was saying was that automated refactorings and compile time type checking will easily catch a certain class of regressions, but unit tests will catch those too. There is another class of problems that are around the change in logic, behavior, or usage that drove the refactoring in the first place which compilers and IDEs can’t catch. The same unit tests catch these.
I’m not saying that stuff has no value, I am saying that the value is very small, and gets smaller the better your test suite gets.
I understand that a good test suite makes a big difference, and is the only solution for catching the class of problems you refer to. However, I still think you’re missing the point that it’s not only about *catching* problems–it’s also about easing maintenance of the application. Ease of automatic refactoring is nothing to scoff at, and it’s just one of many features that IMHO make statically typed languages better-suited to big, long-lived code bases. Most of the features have a lot to do with increasing the power of the IDE, though, so maybe you won’t understand, since you proclaim to still use vim… Anyway, in addition to support for automatic refactoring static typing gives you:
-Auto-completion support in the IDE for member variables and methods
-Built-in documentation support for said auto-completion (the documentation for using a method pops up as you type)
-“Go to declaration” links for method calls and object instantiation, taking you right to the file for the object in question–extremely helpful when browsing someone else’s code base
-Enforcement of best practices (using typed variables whenever possible)
So far you’ve listed all the ways in which statically typed languages “don’t solve all that much”. How about giving some arguments for what exactly dynamically typed lanugages *do* solve?
You mean the hypothetical perfect test suite?
I could as well knock my shoes 3 times and ask for santa claus to refactor my code.
It doesn’t need to be perfect to catch the class of errors that compiling catches.
My stand on the whole thing is you should be doing TDD no matter what you are coding in, but ESPECIALLY dynamic languages. If you practice TDD, even if you don’t go for a really solid test suite, you will catch everything a compiler will catch, plus a lot more. If you don’t practice TDD you are right, refactoring gets really scary. But without TDD you also have no real confidence in your code (or shouldn’t anyways), and relying on the compiler gives you a false sense of security. Again, your test suite does not have to be perfect, but it does need to be broad.
I know the party line perfectly well, I’m a long time member of Python community.
I just don’t really buy it, nor do I buy into the TDD thing. TDD is applicable to a limited set of problems, which are not usually the same things that are problematic in the real world.
Also, see
http://www.artima.com/intv/abstreffi2.html
That link is basically the party line of the other side of the arguement
I don’t know how much value there is left in this conversation, but I will adress that link.
I find “balance = get_balances” exactly as clear as “List<decimal> balance = GetBalances();”. The names of things make it obvious what is going on. The only time the second option will be more clear is in the case of “thing = do_something” vs “int thing = DoSomething();”.
There is additional onus on the developer to write clear code, and bad developers have the ability to screw you _way_ worse. If I had a team of crappy developers, there is no way that I would ever use a dynamic language.
If you are in a good team of experienced folks who know how to write clear code, you are really barely losing anything. What you gain however is enormous. Java/C# style type systems are just about as inflexible as you can get (as opposed to say, the scala or haskell approach to typing, which makes a much better argument for static typing). When you have an inflexible language, you need to write huge amounts of code to get around that. That is code that takes time to write, time to test, time to compile, gives more surface area for bugs, and more surface area to search through when finding bugs. I have loads of experience in massive, enterprise apps in C# or Java, and can honestly say that if you are doing it right, at least half the code has more to do with introducing flexibility then actually solving the problem you are trying to solve.
Alan Kay actually goes further, he says that dynamic dispatch style message passing is more important in OO then freakin Objects or Classes, and he invented the damn thing!
The main argument for static typing is performance, plain and simple. You are spending additional time writing for the compiler, letting it do things the most efficient way possible. The more typing you do for the benefit of the compiler, the more efficient things get. Going in the other direction, the less typing for the compiler you do, the easier things get to understand, design, and debug. Looking at the spectrum, I am sure you wouldn’t have a problem with me saying that C# is more appropriate then assembler for large projects, due to how much easier it is to write, design, and maintain. All the same reasons that I would say that also apply when I say python or ruby is more appropriate for complex systems then something like c# or java.
Now, I know for me, it took almost 3 years between when I heard that argument (specifically, this blog post http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html), and actually fully believing it. I know loads of people who I respect who disagree with me, and I don’t really have a problem with it. What I do know is after 7 years doing enterprise systems in java and c#, the rails codebase that I work on now is is like a dream to work on and maintain. Seeing how fast our competitors can move, I finally understand why Paul Graham never really bothered paying attention to the competition if they were using java or C++ when he did viaweb (in lisp), and pretty much kicked off the .com boom. He knew there was no way they would be able to catch up (let alone keep up).
I agree. Dynamically typed languages are great for little snippet-style programs like thing kind you usually see on web sites, but there’s no way I’d want to use one for a medium-large project, e.g. a web browser or a word processor.
Yes, Javascript suffered for years as an ignored “Toy” language because serious programmers didn’t write HTML pages and the people who did couldn’t write for crap, which made the corpus of Javascript code crap, which made serious people take it less seriously, and so on.
As the web became more mainstream and serious programmers started taking over from half-assed webmasters and started to actually need to use JS, things improved. And then there was jQuery, which proved once and for all that scripting the DOM doesn’t have to suck. The rest is history (and also the present).
The big thing going for it:
javascript has won on the browser side. It *is* the most prevalent technology aside from html itself.
Theoretically it’s personally more appealing to me to limit my number of active languages. Javascript taking over this part means I can start to ignore java even more than I already have.
The reality is that the huge java infrastructure that’s already out there for web services isn’t going to go away any time soon.
Java will always be powerful in the enterprise where middle-ware, high availability and solid data persistence are an absolute must.
I do see JavaScript taking over on the webapp side though, it’s so easy to write and rapidly test that it’s a great choice. I just wish the JavaScript source model was as organized as Java. I always feel so messy doing a project in JavaScript.
There is nothing keeping you from namespacing your functions in javascript, or using more then one file.
For Java to “always” be that, it needs to trim down its libraries, align its framework better, make better development tools, get better application servers, and stop being such a resource hog.
Eclipse, NetBeans, and IDEA aren’t good?
Not as good as they could be. They’re written in Java. Bad choice for Gui.
Too late to edit a late night comment, but I do like many things about eclipse. It just has a lot of Java realted Gui things that make it suboptimal. Rewritten in QT C++ and it woudl rock. Kdevelop is pretty good, but lacks some of the language support and features of Eclipse.
the debugger in eclipse still sucks.
As an Intellij user, all I have to say is, I know.
Eclipse is truly terrible. Netbeans isn’t bad, but it is still quite slow and unresponsive. I’ve never used IDEA.
In contrast, Qt Creator or Visual Studio are nice and snappy, and both are much simpler than Eclipse, which has one of the worst UIs I’ve ever used.
I don’t think javascript can compete with scala. Scala is a language with too many modern features to be targeted by javascript or even java.
Also I think scala can send java in the hell, because it is, from a practical point of view, the true successor of java.
Javascript is an excellent language for the web, but it just seems so low level to me compared to something like Java. You could probably save some LOC using Javascript, but Scala or Groovy on the JVM would be tons better semantically (and LOC wise) than javascript in my opinion. Python and even PHP would be great as well.
My other concern is that Javascript was never meant to be a server side tech and so how secure is Javascript? I feel like people used PHP in a very unsecure way for a very long time before people realized how to write security conscience code.
I would not call javascript excellent… it’s just the only thing we can use without installing a plugin.
It works great when all you need is a few blinking or moving things on your web page but is be a nightmare to use on a large scale project. This is why, as someone else pointed out, Google came up with GWT.
For someone who first learned programming by adding pieces of JS to their web pages I can understand they would be tempted to start writing server side code in the same language.
But those new server side JS framework better have good development tools. Because once you have several dozen files and tens of thousands of lines of code, JS is pretty hard to maintain.
It’s all backwards. Instead of bringing JS to the server, they should bring Python to the browser, now that would be cool
Something like Python or Ruby in the browser would be great! If the browser really should be the development platform of the future it needs to support more than just JavaScript.
I thought python in the browser was possible, but I can’t find any reference to it on the web. There was a perlscript that could be run in IE, with a plug in. That was pretty cool, if a bit useless.
Edited 2010-09-10 14:49 UTC
The was pyxpcom for mozilla, but it’s not maintained and you had to compile the browser and python bit yourself to make it work. Python is a much nicer and cleaner scripting language than javascript. Also much easier for people to learn. It would I think be a great addition to a browser.
http://www.h-online.com/open/news/item/Mozilla-Labs-launches-browse…
Like this perhaps?
Javascript isn’t the problem. Shitty JS programmers writing shitty JS is part of the problem, and part of it is the DOM.
If the ECMAScript people would sit down and finalize packaging, namespaces and a few other little things that people have been clamoring for for years now then JS would be ready to go. As it stands today it requires more effort to do things properly… but that’s like saying C is harder than C++. You can, incidentally, blame Microsoft for dragging its feet here (they don’t want to fix javascript because improving it would undermine their dotnet-in-your-browser initiative).
Ten years ago I might have agreed that Javascript sucks and we only use it because there isn’t another choice. In fact, I believe I said something like that in just as many words… ten years ago, when I was a fool and didn’t really know anything about Javascript. All JS is missing is a little toolchain love and a little more language tweaking, both of which are seriously possible if you don’t have to worry about cross-browsers (which you don’t, server-side).
Guess what. GMail is written in javascript — no, not just the front-end you see, the back end too. Nearly a half million lines of it.
For some reason, most programmers don’t seem to trust dynamic languages for “serious” or “big” work, as if strong typing is a magic bullet. However, static typing, when you think about it, doesn’t solve *any* of the *hard problems* in software development, and, in fact, sometimes even stands in the way.
Javascript is certainly no panacea (more so on the client side than it is on the server) — in fact, its probably the most poorly put together language there is that has achieved any sort of popularity. But there are some nice things at its core — prototypical inheritence, first-class functions, closures, regex — and if you take the time to boil away the ickier parts of the language then you’ll find a fairly graceful language hiding beneath.
The language has some evolving yet to do to make it better, but its quite usable now if you follow the proper idioms and avoid certain language features.
Yet another Java is dead, or language/platform/runtime X will replace Java, article.
I’m no Java apologist – it has lots of warts, particularly the JEE space. But Java remains the number one language (Tiobe index), has more job postings than any other language, and continues to actually gain in popularity. This, despite all the pundits, as well as self anointed “kool-kids” in the blogosphere, predicting its demise.
Javascript a replacement?? Hmmmm
Java the language is rather dated, everyone knows that (i’ve heard sun people say as much in podcasts) except for java fanbois and clueless writers. The thing is that the big players that use it don’t want it to change, they pretty much just want the same thing, faster, and more secure. Java is pretty much the new COBOL, and will remain so for the foreseeable future.
node.js is _the_ new hotness, I haven’t seen anything hyped so much in certain circles since rails. That has sort of made javascript the new hotness.
As a writer, why would you compare the stable workhorse with the new hotness? It’s like comparing html to C, they are completely different things used for different purposes to do different things.
Java was the new hotness about a decade ago, but it hasn’t been for a really really long time now. Acting like javascript is knocking it off of some sort of horse is sort of inane.
RingoJS is an implementation of JS with Common bindings on the server. It’s written in Java and is actually extremely fast. It also allows for any of the umpteen billion Java libs, servers, parsers or languages (including Java it’s self via JSR 199.) to run inside the VM. I’m no evangelist, but just a heads up. Java may be headed west, but it’s VM will live on for decades.
The language itself, no one cares about. I don’t a language is ever chosen for a specific project, because of the language itself (syntax & stuff like that).
It’s chosen usually because people have experience with a specific language, and because there are useful libraries which the language provides (and those libraries have a friendly license).
Java is a million years ahead of Javascript regarding server side programming. It is probably a million years ahead of everything else as well (C++ or .Net probably are closer). But Javascript? No way