Agreed, maybe. All this "the language/platform is just a tool, become a better carpenter" stuff is too clever by half. If you haven't played with CoffeeScript + socket.io + express + etc recently, I'd highly recommend doing so now.
I'm in a similar position of looking at node.js a year or two back and thinking "this has promise", but gave up after hitting wall after wall, four layers of callback-clusterfuck down, trying to do anything real. But things have changed.
The combination of the crazy stupid money Google et. al have poured into VMs with payoffs on the client and server-side, the scalability of event-driven coding, the rapidly evolving breadth and quality of the node.js ecosystem, the modern powerful feel of CoffeeScript, and the slick simple abstractions provided by socket.io (why are there not compatible server-side libraries for other platforms?!), really are starting to give JS that Yegge "next big language" feel.
If you'd told me 5 years ago there'd be serious companies replacing nginx/apache with a dynamic reverse proxy written in javascript, I would have laughed in your face. Now it's reality.
I'm baffled by people's obsession with finding The One Programming Language. Would the world be better off if everyone spoke and thought in only English?
Well, if everyone in the world spoke the same language (whatever it happens to be) then more or less everyone would be able to understand one another. It'd be easier to develop speech software with only one language's worth of idiosyncrasies. So yeah, I think the world might well be better off as a whole.
If the world standardized on English, it would help improve global efficiency and communication. As it is, English is the lingua franca of business and software.
However a large part of culture is language, and countries are always trying to maintain their own.
We're also all pretty biased since this discussion occurs in an English-based community. If Chinese were to become the dominant world language, I bet there would be more resistance. The imperial system is a prime example where Americans are a stubborn cultural holdout.
Another concern is that language helps shape one's beliefs. Multilinguals understand that there are certain cultural concepts in native languages that are difficult to translate. Likewise, being a single language developer--whether it's Javascript or Lisp--influences how a developer approaches problems.
I think the reverse also holds. A large part of language is culture. The meaning of a sentence depends on the context and culture is a part of the context.
I believe if all the world started speaking the same language it would quickly diverge into different dialects and (sub)languages.
I don't think natural languages are a very good analogy for programming languages.
But the world where everyone can speak English, is certainly a better place.
Going off topic here but: I won't disagree with the utopian notion of a world where everyone have a common lingua franca, I think that would be a good thing as well. There being only a single language though, that's definitely not a very positive thing.
You've missed the point a bit. Perhaps having everyone speaking English would be helpful -- but what if everyone spoke only English? Would the world then be better off?
With respect to this question, I think natural language is a very good analogy. And so is biological evolution. Diversity, exploration of thought, and experimentation with expressiveness are very important aspects of having and using different programming languages.
I agree with your sentiment, but there is still a lot to be said for being able to use the same language on the server and client within a single application. I'm currently investigating ClojureScript for this very reason.
Why do so many people consider using the same language on the server and on the client to be such an accomplishment?
We had exactly that situation for many years. We'd write our server software in C or C++, and we'd write our client software in C or C++.
A bit later on, and we saw Java become popular. Soon we were writing server-side code in Java, and accessing these servers using client apps written in Java.
Some time after that, we saw people and organizations more in the Microsoft camp doing the same with VB.NET and C#.
It's only with the relatively recent rise of web apps, and the inflexibility brought on by JavaScript being the only viable scripting language supported by the major browsers, that we've seen this issue arise.
Having to use JavaScript on both the client-side and server-side shouldn't be seen as beneficial in any way. It's actually just a very negative side effect of JavaScript being the only option for client-side web development.
Javascript isn't the only language you can develop web applications on, in the same sense that assembly isn't the only language you can develop server software on. Javascript is what all browsers natively speak, and if you want your language to be understood by a browser, you must compile it down to javascript. The same can be said about assembly: it's the language that all CPUs speak, and if you want your application to be understood by a CPU, you must compile it down to ASM. In this way, you can see javascript as the bytecode of the internet.
So this shouldn't be seen as something negative: it's great, actually, that javascript is evolving in this way. It will allow for more flexibility: you can write your server software in clojurescript, your client software in coffeescript, and still share some common libraries for functions you need to call on both client and server.
I personally have often gotten the impression that a large portion of developers already have The One Programming Language in their mind. It's usually Java or C# or sometimes still C++.
JavaScript fills me with joy because it is so unlike these languages and I get to watch people grow when they stop kicking and screaming and learn it. JavaScript doesn't have any super unique features or anything; it's just so not Java while frequently being suddenly essential to people who think in Java.
I also find it interesting that most people on the thread seemed to have missed the important difference between having a shared language and having only one language!
As an English-speaking U.S. citizen who has studied some German and Russian but is fluent in only English, I can say that I am seriously limited by my ignorance of other languages.
As a programmer who programs in several different languages, I am perplexed that people dream of The One True Language.
Today I am likely to write some R, bash, SQL, awk, in addition to javascript. I don't believe that fear of new languages leads people to imagine I'd be better off using Javascript in all these contexts or that Javascript would be better off if it added the features of all these other languages.
Because most languages are not optimized for a type of task, most languages are not DSLs. Most languages are "general purpose". I don't understand why so many people continually make this same comment.
I started programming with ruby, and was really pretty reluctant to move to less clean languages - it was just hard on my eyes when I was used to reading and writing clean and understandable ruby code.
But javascript won me over in the end, and I now write most of my apps with node. Totally unrelated to hype or to this article or to anything -- the reason why was mostly the challenges that came with switching to js. The two challenges that particularly intrigued me were:
- Making async code clean, readable, and manageable. As themgt mentioned, this is a really tough challenge. It took me months of going over and over my code, continually reading about promises and async flow control etc. to really "get it". And once I got it, it was really empowering, and the ability and choice to run pieces of code in parallel or in series (which you don't get at all with sync languages) is something I'm now very reluctant to give up.
- Writing code that has more syntax (braces, semicolons, low level loops, etc) and still making it clean and readable is a challenge that I think has improved the way I write all code for the better. It's so much more difficult to make javascript adhere to the cleanliness standards that I'm used to with ruby that I spend a lot more time thinking about how elegant and readable my code is and optimizing it for that purpose, which I think nobody would argue is a great thing for a developer to work on.
So without comment on whether javascript is "the" language or "the future", which, as other people have mentioned, is silly to speculate, I would strongly recommend picking up node and using it to build a few apps, if just for the purpose of dealing with the two points I mentioned above : )
This was a disappointing article. Rather than focusing on the strengths of javascript, the author is trying to sell TypeScript. There are many compile-to-javascript languages, but the real strength lies within javascript itself.
In my experience, the JS ecosystem is really strong. v8 really pushed the performance bar, and the upcoming features (stuff like Buffers/Views for contiguous memory) make it possible to write programs that look and behave like C programs. The breadth and depth of nontrivial open-source projects and code segments is impressive, and the IRC communities are fairly vibrant.
I tried an arithmetic benchmark to compare JS performance between node.js and vert.x. As it turns out, the JS implementations under node.js even smokes the Java implementations!
As far as JavaScript goes he's not off the mark. The thing that saddens me a bit is that it's yet another post about a particular language/technology/thing.
No language/technology/thing is better than another. It may be better than another in a particular context. This is as true for Android as it is for Visual Basic and Arduino.
While this is obviously my personal opinion, I think the industry as a whole might benefit a lot more from a post that discusses the pros and cons of building a solution that targets say, the web, a phone, tablet and a desktop. And how such a solution might do authN and authR, synchronise data using store/forward, work in an offline scenario (aeroplane, underground, Gobi desert...).
Talking about specific technologies in such a context is useful. It is even more useful when considering environmental factors such directories, monitoring software, privacy, advertising and so on.
No language/technology/thing is better than another. It may be better than another in a particular context.
I don't really buy into this reasoning. If a given language is worse than every other in almost every context (the "global" context, if you will), then it's clearly an inferior language relative to the others.
JavaScript does exhibit this. It has exactly one thing going for it: it's the only scripting language widely available in web browsers.
Aside from that, it's inferior to most other languages in almost every respect. Its syntax is mediocre. Its semantics are inconsistent and often outright confusing. It's missing critical features that are essential for anything but the smallest-scale development. Its performance is only just somewhat poor today, due to a huge amount of effort from Google and others, otherwise it was downright abysmal in its early implementations. Its libraries are more bandages for its numerous problems, rather than tools that empower developers. The supporting tooling is quite bad (Chrome's developer tools or Firebug don't compare to a real debugger, for instance). The community leaves a lot to be desired, especially given the high amount of ignorance and the extremely bad "advice" that is passed around so often by its members.
We shouldn't be politically correct when it comes to technology. Some programming languages are worse than others, and we shouldn't shy away from saying this. JavaScript is an inferior language, like it or not.
> JavaScript does exhibit this. It has exactly one thing going for it: it's the only scripting language widely available in web browsers.
Other things it has going for it:
- a proper universal unicode-aware string type. Languages which lack this: C, PHP. (Note that i said universal, obviously you can do proper string handling in any language, some just make it a bit too hard.)
- low verbosity and a general lack of boilerplate. Languages which lack this: Java, C++. (Yes, you can write concise code in these languages, it's just that in practice nobody does.)
- Prototypal inheritance. Admittedy, many people consider this a disadvantage, but that's because they were introduced to the inferior classical inheritance model first.
- Everything is an object, always. Languages which lack this: practically every mainstream language out there. Combine this with prototypal inheritance, and it makes javascript the most object-oriented language i know by letting you inherit from almost anything.
- A syntax so expressive it can be easily adapted to do dynamic scoping and namespacing (see crockford's book) without actually needing a namespace syntactical element, which makes it possible to scale it up to hundreds of thousands of lines of code. (The DOM is a different matter, but a different language would feel the pain of scaling that up just as much.)
So, really, worse is in the eye of the beholder. Javascript is different, not worse. Are you sure you've given it a fair chance and aren't just rejecting it for weak typing and the horribleness that is the DOM?
(Btw, you should try a proper IDE like webstorm that has a full debugger for javascript before saying the tooling isn't there yet.)
It's missing critical features that are essential for anything but the smallest-scale development.
What in your opinion is smallest-scale development? Millions of users using your application each year? Do we need web apps to support billions of users each year now?
JavaScript is the most superior scripting language widely available in web browsers. Until there is an alternative it cannot be an inferior language because there is nothing equivalent on which to base a comparison.
I was talking about code base and application size, not so much the number of users.
Using JavaScript for a large application is not a pleasant experience. I know there are a lot of JavaScript developers out there who have never used anything but JavaScript, and maybe PHP, so they don't know what they're missing. But those of us who have used even just C++, Java, C#, or Delphi will know how critical things like static typing, namespaces, proper modularity and class-based OO, for example, are.
Aside from that, it's inferior to most other languages in almost every respect.
Your perspective is semantic. Mine is pragmatic. I want to get a job done, and I want to be successful. I have no interest in the best tool.
If I'm targeting web browsers then JavaScript is the logical choice that will make me successful. It doesn't matter that it's a swamp donkey.
JS libraries are like any other library. The developer makes the choice. I wouldn't, for instance, distribute the Windows Phone toolkit with my app when all I'm using from the toolkit is the ExpanderView control.
JavaScript is the only mainstream programming language that has multiple competing production-quality implementations.
I think this rarity helps to ensure that work is done to improve the runtime, from both an ease-of-development and a performance perspective, while also keeping the set of what works pretty stable.
I'd say Mono/Xamarin and .NET/Microsoft would qualify as competing production quality implementations of C#. Xamarin may have positioned their implementation of C# to target the mobile space instead of the enterprise space because they see that as a losing battle against Microsoft (and the niche they do address is very lucrative right now) but the could still qualify as competitors.
>No language/technology/thing is better than another. It may be better than another in a particular context. This is as true for Android as it is for Visual Basic and Arduino.
Disagree, strongly. Progress exists. The languages of today really are better than the languages of 20 years ago. Android really is better than winCE (and this is speaking as someone who was a fan of winCE when it was the best thing available, and spent a fair amount of effort compiling apps for it), not just in some situations but overall.
winCE today is far superior to Android when creating an app that relies on Active Directory.
Similarly, whilst LINQ may represent progress in that it makes querying XML, an object model or SQL Server easier, it's terrible when the requirement calls for a complex data model that bears little resemblance to the in-memory representation required by the app.
If you look at the definition of "good" in Noah Webster's American Dictionary of the English Language, it will say "fit for a particular purpose" to say that nothing is any better than anything else is to ignore purposes.
Author has some good points. What I don't like is this superficial "the future" label. Hopefully, "the future" won't be about just one technology. In my opinion, it should be more about using the right tool for the right job. Even though I'm a big fan, it's obvious that JavaScript is not the answer to all of you casual programming questions, let alone the very complex ones.
It might seem trite, but a CoffeeScript + TypeScript combination would make me very happy. I have been developing in TypeScript recently because the IDE support is awesome (and I'm a static typing enthusiast). Now if I could just reduce the verbosity and save some keystrokes...
Um, JavaScript is cool and all and you can use it in a lot of places, but for things beyond nontrivial apps, Node.js is going to be hard to scale to larger teams. Maybe that is a good thing. Maybe having a bunch of smaller services talking to each other is the way to go, but so far node hasn't solved the inherent callback soup problem.
I worked on a Node-backed website with a team for a year, and we had no problem with callback soup. However, we did use IcedCoffeeScript which made dealing with callbacks a lot easier. But, scalability-wise, programming in Node was no different from any other language. What do you think makes it hard to scale?
I'm in a similar position of looking at node.js a year or two back and thinking "this has promise", but gave up after hitting wall after wall, four layers of callback-clusterfuck down, trying to do anything real. But things have changed.
The combination of the crazy stupid money Google et. al have poured into VMs with payoffs on the client and server-side, the scalability of event-driven coding, the rapidly evolving breadth and quality of the node.js ecosystem, the modern powerful feel of CoffeeScript, and the slick simple abstractions provided by socket.io (why are there not compatible server-side libraries for other platforms?!), really are starting to give JS that Yegge "next big language" feel.
If you'd told me 5 years ago there'd be serious companies replacing nginx/apache with a dynamic reverse proxy written in javascript, I would have laughed in your face. Now it's reality.