JavaScript is the future...maybe
blog.jonathanchannon.com
blog.jonathanchannon.com
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.
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.
But why complicate things with multiple languages if you can use one? Then all developers can understand and edit the codebase.
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 cannot understand why some developers fail to understand that we need different tools optimized for different types of tasks.
It is like they are afraid of learning.
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.
Hence the need to know several languages and use the right one for the task at hand.
(disclaimer: English is only my third language)
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.
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.
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.
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 : )
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!
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.
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.
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.
That's what I mean by 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.
It has exactly one thing going for it: it's the only scripting language widely available in web browsers.
Please let us change this. We are marching into the future heady with ambition and the common tool is JavaScript. This is a sad state of affairs.
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.
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.
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.
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.)
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.
There are numerous competing, production-quality, independently-developed C compilers, runtimes and standard libraries.
There are numerous competing, production-quality, independently-developed C++ compilers, runtimes and standard libraries.
There are several competing, production-quality, independently-developed Ada compiler systems.
There are numerous competing, production-quality, independently-developed Fortran compiler systems.
JavaScript is hardly alone in that respect.
Obviously, without that qualifier the statement is false.
I would agree if you said language X is more expressive than Y, it can be proved. But isn't syntax totally subjective?
Missing critical features
Which critical features are missing?
Performance .. absymal
Well .. you would not notice any performance issues with typical web apps. You should try it.
Libraries are missing, are more bandages for its numerous problems
Github has an enormous collection of nodejs libraries. Which ones are bandages for language problems?
Tooling
I find text-editors and chrome better than IDEs like Eclipse and Visual Studio.