I'm sorry but I have to side with the JS is utter crap crowd.
The single redeeming feature of JS is that it's implemented in all current browsers. If it wasn't for that fact I doubt anyone would have cared much.
It's just nowhere near as good as current alternatives for application development. Everything it can do another language can do better, except run in a browser - which is entirely out of control of the other languages so somewhat of a moot point.
I'm sorry but I have to side with the "oxygen is utter crap" crowd. It's too reactive, causing all kinds of materials to degrade, and sometimes they even burst into flame! Helium, Neon, Argon are much better, but even Nitrogen, which isn't perfect, is better than Oxygen.
The single redeeming feature of Oxygen is that it's pretty much everywhere, and yeah sure we can all breathe it and don't have any other choices for gases to breathe. If it wasn't for that fact I doubt anyone would care much for it.
Ok, I'm paraphrasing and extending what you said to make my point... Javascript being in every browser, to the exclusion of all other languages, is a huge factor in its popularity and utility, and it's the main driving force towards improving the language. If Javascript didn't become the in-browser language, it probably wouldn't have existed at all. Instead we'd have some other small language with similar design flaws, or maybe Perl would have been adopted as the in-browser language. At the time it was the main language for server-side web development, it was already embeddable and used for in-app scripting (like Lua is today), and I recall a browser extension for Netscape that let you use it instead of Javascript. IE, of course, would only have had VBScript.
I didn't see a point, just a bunch of facts and a smarmy, self-righteous turn-about comment. If I could downvote it, I would.
The parent comment said "Javascript is a bad language but it's incredibly useful because it's in every browser." and you just agreed with him after writing a bunch of sarcastic drek.
No, jpgvm said that Javascript is "utter crap" that no one would care about if not for the fact that it's implemented in all current browsers. She/he never said anything about it being useful. My point, which appears to have gone over your head, is that you can't dismiss one of the key aspects of Javascript's value and then call it "utter crap".
I'm not aware of any other language that makes it so easy to write your code in either a functional or object oriented style. It doesn't do either perfectly, but it gets you a good 85% of the way there for both. Good enough that advocates of a particular style are able to write and enjoy writing JavaScript. I can't think of any other language that has that level of flexibility. Can you?
>I'm not aware of any other language that makes it so easy to write your code in either a functional or object oriented style
>I can't think of any other language that has that level of flexibility. Can you?
(Subjective opinion here)- I think Lua got it better; you can create a better object oriented program with it, as you can do it with functional style; Ending with a more elegant final source code down the road
Yeah, agree Lua did get it better. JavaScript is very much inspired by Lua, but has the disadvantage of having more "cooks in the kitchen" wanting to mess with it.
I disagree strongly w.r.t. Python as anonymous lambdas are heavily restricted there. I disagree less strongly but also somewhat insistently about Ruby where the distinction between methods and functions is warranted but thus involves more overhead.
JavaScript is hospitable enough that you see entire applications written in a functional style. Where is the Python and Ruby applications written mostly in a functional style? I've never seen any.
I've yet to see entire JavaScript applications written in a functional style. Just because "map" is used more often than Python doesn't make it functional.
> Better at being both a functional and object oriented language?
Well that's both subjective and ambiguous (subjective in the evaluation of quality in each area, and ambiguous because the meaning of "better at a and b" can be interpreted in a number of ways, such as max by min(a,b), max by average(a,b), etc.
But, given that, I'd say that several of the listed languages are better at "being both a functional and object oriented language" than JavaScript, including Scala and Ruby.
All over. Various functional approaches are basic core Ruby programming techniques.
Its not a great FP language because it lacks functional purity (like most Lisps, and, more to the immediate point, like JS) and the main Ruby implementations lack TCO (as, again, do many Lisps and, again, JS.)
But there's certainly a lot Ruby code using functional style.
I didn't ask which are "better", I asked which are better at being both functional and object oriented at the same time. I can accept Lua, but the others I really need a good argument for.
They are all better at both than JavaScript. There is no feature that JavaScript has that the other languages don't, often in very similar shapes. The reverse is mostly not true.
Being a non-JVM developer I can see that e.g. Scala is actually trying to innovate, trying to combine best features and learn from past mistakes. But it just grinds my gears when modern JS is represented as some sort of "innovation". How can so called "Open Web" be open if the only realistic option I have is JS+HTML or something that will be painful to debug in a real world job.
"The intrinsic smallness of the language can be alarming when you come from a bigger language (Ruby, Java)"
Bad examples. Ruby and Java are small languages too, just like JS. This immediately calls into question the credentials of the author. Not a good start.
"Null everywhere Attempting to access a property of a JS object that’s not defined gives you… undefined. If it’s important to your program that you know about this: write some code."
Or just, you know, use a better language?
"‘Callback hell’ isn’t a problem for people who’ve written a lot of JS."
So that makes it okay then?
It's just another article written by someone so immersed in their own little world that they can't see the wood for the trees. The author probably thinks he has put together a nice a little counter-attack to that "other" article; but really he has just reinforced it.
Actually Ruby and Java are both large languages compared to JS. Ruby especially - compare its object system with Javascript's, or consider it has 3 flavours of lambda ;)
Nice to take 2 quotes out of context of their explanations.
And finally, I've written a heap of Ruby, Python & AS3 and enough Clojure, Haskell and Go to be able to say: Javascript is a great little language. We use it because of history, sure, but learn how to use it before bashing it.
The whole article just seems to be missing the point entirely.
It pretty much answers everything with "oh but you can write a hack to work around that" or "oh there is some library you can use that plugs that gap". Whilst yes, these may be viable "solutions" for hacking something out. It doesn't refute the claim by the original article that JS is a bad language. It actually just reinforces it with yet more examples.
The only positives to take away from the article are where it highlights features coming in ES6 to actually solve some of the problems. But these admissions seem to contradict the premise of the article.
No I'm not missing the point: I show how, within a few lines, these 'missing features' disappear. e.g: constants, type annotations, objects as keys.
Adding a whole language feature to save a few lines of code - not to my taste. You don't need a new language feature to express an idea if it can be trivially expressed in the language as it stands.
I didn't like the constants solution for nulls. Why not use a Maybe monad? I'm surprised that you didn't considering your claimed language experience.
I guess I just don't agree with your fundamental position on this. That writing yet more code to workaround a bad language is in anyway a long-term solution. At some point you'll want to bring more devs onto your team and then you'll need to explain all this technical debt and hacks to them. Not good.
I still believe you're missing the point of the original article you were refuting. It's not about being able to workaround something. It's about not needing to workaround flaws in the language in the first place. That's what defines a good language.
I cannot comment on Ruby. I, personally, think Java is a much bigger language than (base without other scripts included) Javascript. Of the two, I prefer Java for it's strong types. My biggest problem with Javascript is that if I make a typo on a variable name, it can be very difficult to debug. This could perhaps be mitigated by using an IDE, I don't know since I don't use JS that often. I feel like this is not a major issue and work on LLVM+emscripten will let me work in almost whatever language I want and have it end up in Javascript in the near future.
From my perspective, Java has, effectively, structs (well defined groups of data) and a few primitive types, and a class system which is dead simple. It's tiny, comparable to Lua imo.
It's more restrictive, sure, but the dynamic-ness of Javascript is a hindrance when it comes to language spec because the base language functions need to be able to interpret all the different primitive types. There's stacks and stacks of corner cases to remember while Java just says "Nope, wrong type".
I'll give you generics. Statics, method visibility vs global/local/self. Interfaces, abstract classes, inner classes vs metatables. Data-structures apart from array are implemented on top of the language, array vs tables. Iterators are implemented on top of the language vs lua where they are part of the language. Checked exceptions can just be cast to Exception and ignored. Annotations are optional. Threads vs coroutines.
Yes, comparable to Lua. I'd probably not say it's smaller than Lua but I would say it's not greatly larger than it.
I think Java is bigger in terms of the amount of classes/methods that there are to remember. Perhaps I compare them unfairly because I consider everything in the SDK to be a part of Java, whereas the things people might usually bundle in JS (JQuery, etc) I don't consider part of JS because you have to go out and get them separately. I didn't mean bigger in the sense that you need to know more to be able to use it, I meant it in the sense that it is a larger API.
>I didn't mean bigger in the sense that you need to know more to be able to use it
Ah ok, well I can see why we have differing opinions because that's exactly what I mean :)
I mean base language including corner-cases, not any of the libraries (even if they're included in the SDK). I think they'd both be huge if we included libraries, since I'd lump in DOM manipulation and something like JQuery into Javascript if Java gets the SDK libraries.
Just a couple of examples. Arrays and Objects are the same type of structure in JavaScript. Arrays just happen to be indexed by integers and Objects by strings. In Java this is not the case.
Another example, in Java Classes are not objects that can be manipulated, they require a special form (generics) for that. In JavaScript a "class" is just a function that has some default properties attached.
Just a couple of examples. Arrays and Objects are the same type of structure in JavaScript. Arrays just happen to be indexed by integers and Objects by strings.
This description doesn't tell the whole story, leading people to a false conclusion of simplicity.
When it comes to JavaScript arrays, a lot of magic is happening under the covers that doesn't happen with non-array objects. Good JavaScript developers need to know those details, and that counts as complexity.
You're doing people here a disservice by leaving out relevant information.
The associative arrays in JS are simpler than objects in Java but the expressiveness means you need to be aware of all the different types of type coercion and how it all interacts at runtime. I don't think this is that difficult but it's no more difficult to lay out your data before runtime. I think this is a wash that goes to the dynamic vs static debate which we all know can be argued about for days.
You're leaving out prototypes which I find much more complicated than Java Classes.
But the discussion isn't about complexity, the discussion is about "smallness" and prototypes are definitely small. They are just "bags of properties" like all JavaScript objects. They just have the special function of being automatically applied to a new object's "__proto__" property when using new. Compare that to Java, where Classes are not objects themselves, they are blueprints for creating objects. But the distinction there means if you want to reason about Classes you need a special form in generics.
Javascript suffers the curse of popularity in spades. Most of its users today do not use it as a language at all, but instead as very light mechanism for getting a web browser to do weird things. Using Javascript as a language isn't bad and I think that's worth talking about. Especially since putting more effort there may let Javascript take advantage of some of its popularity.
Javascript is definitely microscopic compared to Ruby or Java. Lua, Smalltalk, Scheme have it handily beat on size, though. Furthermore, Haskell is absolutely lightyears ahead of Javascript in semantic niceness, but it succeeds there by being a much larger language, so YMMV.
I'd think there is a reasonably good metric in there around approximating Kolgomorov Complexity: "What is the size of the shortest written description of the entire spec of a language?"
This completely discounts expressivity, of course, so perhaps a related measure would be, given a suitably complex and representative programming task "What is the size of the shortest written description of the entire spec of a language plus the shortest program in that language that solves said problem."
None of these things exist nor can be computed. They also still ignore readability (something very important and for which Brainfuck would likely fail), but I would wager a reasonable consensus could be built around the concepts.
For example in JavaScript you can easily write your own version of new. JavaScript is a just a "bag of properties" and everything else follows from that. Very very rarely do you run into something in the language that breaks that expectation.
"‘Callback hell’ isn’t a problem for people who’ve written a lot of JS."
So that makes it okay then?
I don't know of any language that makes it impossible to write bad code, do you?
JavaScript is a great language, but it's one that's been full of problems as well. It's great because people who traditionally aren't developers can get some JS snippet running to add something dynamic to a site, but at the same time if you are a developer who has spent time learning the language then you can do a lot more with it.
There are also alternatives to callback hell. I do take the method of naming functions instead of using a large number of anonymous functions. It helps significantly. If you prefer, you can easily use promises instead. That's been another effective approach.
I've never written any Ruby and can't speak to the comparison at all, but if it's a language that makes it impossible to produce bad code when you don't know the language and its idioms well then it's something I need to be learning.
Often when discussing JS as a language the conversation drifts off on tangents talking about all the amazing and wonderful libraries available for it. Unfortunately this is sorely missing the point. The conversation is about the language, not its ecosystem.
What do you think libraries are written with? Glue? A language has a direct impact on a library, so no, you can't get out of that one this easily. Either defend your point well or don't try anymore.
Just because a book whose subject matter is of how to write better English and it itself is written in English doesn't make English itself a better language.
I feel like making it hard to write code tend to correlate with making it hard to write bad code.
This is a problem since many programmers do not like languages which make it hard for them to write code. I'm not sure whether it's the effect of "making it hard to write bad code" that makes it hard to write code or whether its "making it hard to write code" that makes you less likely to run into the effects of bad programmers.
I think one of the arguments for Ruby over Python is the whole Theres More Than One Right Way To Do It philosophy which does make things significantly easier to write down in Ruby, especially coming from scratch. This is much like Postel's principle---a computer should be receptive to many slightly malformed inputs because they will happen. That makes the computer more successful.
The problem is that once you start accepting malformed inputs you can never be rid of them and thus you have a permanent tower of babble[1] problem.
No, you can write bad code in Ruby. Ruby's advantages are that it's insanely flexible, very OO, very easy to write and get started with, but has lots of very powerful features. But in some ways Ruby is like C++; it gives you alot of rope to hang yourself with...
And JS has some incredible flexibility, with CoffeeScript (CS after) you can even get a more terse syntax similar to ruby/python.
JS is not OO... IMHO OOP has not proven itself out to reduce confustion, or simplify code bases. It tends to make distributed systems which are increasingly necessary for large projects more complicated. In JS I tend to have two types of objects. The first being data, that which can be easily serialized, transported, stored and deserialized. The second being libraries meant to act against requests or use of said data. The second can be extended to those which tie a user interface to said data as well.
When you break things down in such a way it's easier to develop systems that can scale out, and are easier to maintain as such. You can do similar things in most OO environments. I also tend to think that my Duck data class should probably NOT have a quack method. My DuckHandler class should.
OO has brought us a lot of extremely bloated, over-engineered, "enterprise" monstrosities over the years, and imho should not be encouraged.
JS is very much my favorite language, and in some scenarios (testing, and build scripts) I have started to use CoffeeScript. My second is actually C#, which I pick over Java because JNI is such a pain by comparison. It really depends on what you need.
Sometimes you just need to get something done. You will not be able to use Ruby or C++ in client-side browser code any time soon. On the flip side node.js as a binding layer against a very nice set of C libraries is pretty awesome, and can be used to get closer to a "one language to rule them" ... it's often said, "don't let perfection get in the way of good enough."
JS is definitely OO; its not class-based OO -- but its still OO. And its purer OO than, e.g., Java (class-based OO in which classes are not first-class objects but require jumping through hoops to get an object that represents the class are not as much OO as either protypical OO languages that lack classes as language features like JS, or class-based OO in which classes are objects like Ruby.)
> IMHO OOP has not proven itself out to reduce confustion, or simplify code bases. It tends to make distributed systems which are increasingly necessary for large projects more complicated. In JS I tend to have two types of objects.
IMHO, OO languages, per se, do not have that effect, though Java has that effect, due to the same limitations which make Java the poster child for repeated-code-template style design patterns.
OO has brought us a lot of extremely bloated, over-engineered, "enterprise" monstrosities over the years, and imho should not be encouraged.
When done correctly, object oriented programming is a lot like the Unix philosophy.
The Unix philosophy (in part): Write programs that do one thing and do it well. Write programs to work together.
Correctly done object oriented programming: Write objects that do one thing and do it well. Write objects to work together.
There's a lot of very poorly written non-OO code out there. Don't blame OO because there's also a lot of poorly written OO code out there. OO is, in part, a tool to manage code complexity. Blaming OO for complexity is like blaming Unix for complexity because there are too many programs in the /bin directory.
> And JS has some incredible flexibility, with CoffeeScript (CS after) you can even get a more terse syntax similar to ruby/python.
CoffeeScript isn't JS, its a different language that compiles to JS. So what CS can do doesn't say anything about JS as a development language.
> You will not be able to use Ruby or C++ in client-side browser code any time soon.
You can use C++ in client-side browser code now -- sure, you compile it to JS, just as you compile it to native binaries to run on the server side, but the development language can be C++. [1]
"There is no need in this world for manual screwdrivers because a drill can do the same job with less work."
I don't understand the vitriol. Is JavaScript perfect? No but I don't think anyone has ever made that argument. Can you build web applications with it? Absolutely.
The fact of the matter is JS can run on more "things" than anything else. Period. This includes legacy systems. Don't like the language? That's totally fine and, to an extent, understandable. But, holy shit, it's a highly accessible tool: learn it and stop complaining.
"But there are better tools!" Ok, that's great, but those tools aren't presently available in your toolbox. So write your own library to implement missing feature x. Syntax not terse enough for you? Write a preprocessor. Since you won't be the first, a lot of the hard work has already been done for you. Consider publishing it. Do what every other developer doing anything on the web has had to do for years: improve your sandbox.
"But these features should be standard!" They're not. Write the 3-5 lines to fix it and move on. Want to go the extra mile? Talk to the folks who run the show (the ecma folks).
Not happy with the tools? Fix them. Chromium and Firefox are OSS; write other runtimes into them. Push for their adoption. Does that seem like an insurmountable task? Then perhaps leverage what is available to you.
How does it not blow your mind that you can write one bit of code and have it instantly available on the vast majority of devices released in the last 20+ years? Yeah, you'll have to write polyfills and hacks, and there will be a lot of boilerplate, but think about that for a second: one bit of code and it runs on phones / tvs / computers / calculators / toasters. Do you have to write it using a tool that was originally designed for a dramatically different environment? Yup. Can you still do it? Yup. How is that not amazing?
C and even C++ run in far more places than Javascript does or ever will. People using other languages won't be interested in or able to use your library written in Javascript.
Anyway, I don't particularly care about writing code that runs on every device ever. I want to write code to solve problems, and for a large set of problems Javascript inside a web browser is fairly useless. Javascript is great if your economic model is getting as many users as possible and then getting aquhired before you run out of capital. This is the case for a lot of people on HN, even if they don't realise it. However I'm a small time developer, not in SV, who programs because I enjoy solving problems and helping people, not to get rich. I'm only really interested in whether $(number of people who can run the code) * $(how much they can pay) > $(my cost of living) so that I can afford to eat. It means I don't care so long as the platform/language I choose has enough users to pay my bills, it doesn't have to be 100% of people. I realise that the industry giants at Google or Mozilla don't really care about people like me ('life style business' is usually a term of derision on HN). In a world of web based operating systems that only run web apps I would end up stacking shelves in the supermarket or on the dole because I dislike that technology stack enough that I can't be productive in it. That is why sometimes I bitch about Javascript.
I don't understand how you connected Javascript with that particular start-up mentality. "Solving problems and helping people" as a development approach is platform agnostic; if you wanted to do that through the web then hey, you would probably use Javascript to accomplish that.
My point is that the benefit of Javascript (i.e. being able to run on all consumer computers with (almost) a single code base) isn't a benefit that interests me. I tried to explain why because I know that a lot of people on HN have very different reasons for wanting to develop software -- people don't apply to YC because they are building a small lifestyle business to support their family.
>if you wanted to do that through the web then hey, you would probably use Javascript to accomplish that.
Well personally I wouldn't since as I said I'd rather not develop software at all then use Javascript/CSS/HTML.
Of course the rest of the industry has no obligation to continue supporting the open native platforms that allow me to use the technologies I prefer. However I don't think it is unreasonable to moan when I see those platforms being killed.
I wish you wouldn't bitch about it at such length with a point that barely makes any sense. 'Only SV posers use JS". Everyone who has a computer, whether handheld or a laptop or whatever, has a browser. There's your distribution. How you blamed its problems on startup mentality I don't even know how you got there.
I think you are just reenforcing my point. I really don't care about targeting 'everyone who has a computer'. Really. I mean it.
I want to use technologies that I enjoy, and I can do that so long as enough people use computers that I can deploy those technologies to.
What I don't want is to be forced to use technologies I dislike just because it's where the money is in the industry and the people with power have decided it benefits them to sell devices that only allow software that runs in the javascript sandbox.
Maybe the reason right now this is where the money is because consumers demand more of the capabilities that Javascript can give them, not because some overlords decided this was going to finally get those lazy programmers.
Personally, I enjoy writing in Javascript a lot. I like how it's more functional than other mainstream languages. And if we're going to debate style, that's great, but distribution just isn't a problem of Javascript, instead, one if its greater strengths.
Your post complaining about complaining doesn't make the best case against complaining in general.
You're just bitching in the opposite direction and telling people that unless they agree with you on the topic, they can't express their opinion in same rhetorical style you do.
Two facts mentioned in the video that I didn't previously know and make me feel better about JavaScript:
1- JavaScript is lisp in disguise
2- The name JavaScript is an inside joke referencing the language's differences from Java, not its similarities.
That was enough to make me change my mind, and I'm currently enjoying learning JavaScript unashamedly. Browser differences and lack of standards are a PITA, but OTOH, they all have awesome debuggers - HTML+JavaScript may be the only UI toolkit + dev environment that comes packaged with ALL computers, and for that reason has the widest reach.
There's no question that the JS world is a bit wild west compared to other languages, but there's also no question that the situation is getting better over time, and that depending on what you're coding, there are huge advantages to using it.
This is an opinion post, not a statement of fact. There's also no byline on that very hyperbolic and negative opinion post. I don't need to defend JavaScript's Schemeness or Douglas Crockford. (I'm sure Douglas is perfectly capable of doing that by himself.)
The obvious authority argument: Given random dude on the internet (heretofore to be known as "Stuff" in reference to his web site), and the guy who wrote jslint and is currently fixing JavaScript, on the topic of what other languages JavaScript is most like, I will defer to Douglas for now.
First and foremost in the actual reasons "Stuff" is wrong is this claim:
[saying javascript is scheme is] "...a thought-terminating cliché. It carries negative informational content and makes people actually know less about languages than they did before."
I am walking talking evidence that "Stuff" is dead wrong on this point. The idea that JavaScript has the functional language parts that I like in Python and Scheme made me curious about the language, allowed me to drop by preconceptions, and I investigated further and learned more about the language. That may well be the exact intention of Douglas saying JavaScript is Scheme-y, which it turns out, "Stuff" admits to before he gets started. This completely undermines the point that "Stuff" was trying to make here, before he makes it.
Second, "Stuff" capitulates to 1/3 similarity on the number of core Scheme features. Except, as he notes, another several are reasonably there but not up to his snuff. That puts us at more like 1/2 to 2/3. The other third is crap nobody wants in a modern language. "Stuff" is being (admittedly) biased about where he draws the line.
The most telling is that he points right at the things that we all want in a language: minimalism, first class functions, and closures. He comes right out and names all the languages we like and hold up as being "better" than JavaScript. :O There's no better reason to call JavaScript Scheme-y.
This. The great thing about JS, and time has proved this, is just how powerful a concept it was from the start and just how misunderstood it was. Just because people misused the flexibility of the language does not make it a bad one.
As the JS engines in browsers have got better and more "real developers" have come on board the wild west is no longer so wild. The problem I found before was that front-end developers would code JS but they had no formal education in programming, so they couldn't grasp those OO concepts. If you look at some of the libraries and JS code out there now you'd be amazed at the standard of code. Most of it far beyond me now, I haven't coded in JS in some time.
The religious debate between people being practical and the various kinds of people who attack them will rage on forever. In most online communities, the haters and purists will typically win arguments, because they generally have more time and patience to argue than the people busy getting things done.
It's basic human nature for us to behave this way. It's tribalism: "it's not how I roll, I don't understand it, therefore I hate it" is pretty natural for us.
I really don't get all this rage at Javascript. Obviously it has flaws and warts, but I don't see it as being significantly worse than other dynamically-typed languages. Yes, there are some misfeatures we'd all like to see ripped out and those provide some nasty gotchas. But once you learn the language it compares well to Python and Lua and other dynamically-typed C-ish-syntax languages.
There's significant danger in the fact that people don't know that they need to learn it. They just write what they know, and techniques that are actually supported across all browsers they're supporting (with IE8 or hopefully IE10 being the minimum supported browser) lie unused for quite a few years. That these techniques need deep knowledge to make a solid result indicates a point of concern in the suitability of JavaScript for such things. Are ES5 and ES6 merely papering over the problems where a fresh-room approach might work better? (My answer: I frankly don't know. In the very long term, replacing JavaScript might be a good thing, but it would wreak significant havoc for quite a few years and would be impressively difficult to orchestrate from the browser manufacturers' perspective.)
I'd still love to have the safety of a language like Rust for modern web development. At some point, someone will fix Emscripten support up for it, so then it'll be comparatively alright. (I like the theory of the one-language-from-end-to-end approach, but I want it to be a safer language than JavaScript.)
Just saying that JS has a good debugger (it isn't that good, really) isn't nearly enough to counteract the original points about terrible exception handling. Exception handling isn't just about fixing errors, it's about controlling the flow of errors through your programs and handling them as best you can. Your customer doesn't want to step into a debugger to see what went wrong, they just want a nice error message.
Web applications are only small part or "modern development", so no you don't need to learn js. Unless you're working on a "cool, but ultimately useless" web apps, JavaScript is useless.
I probably should have titled it "Javascript isn't a shit language, you just need to learn it" to avoid this ambiguity: I'm not claiming it's a "must learn" for modern dev ;)
Javascript is shitty, though. I say this as someone who loves it, enjoys using it and understands it better than most. There are just some real undeniable fuck-ups in the design of the language. Don't get all defensive about it, be honest.
Great article. While JS isn't my favourite language, it has many redeeming features. For one, to get started, just open up a browser console, and have at it! No other language offers such a low barrier to entry. You can create a simple HTML file, run it strait from the browser, and voilà, you have a program.
Javascripts flexibility is why you see emulators, 3D games and simulations, everything written in Javascript. Every language compiles to Javascript, and you can edit code live in Javascript, having it render directly into the browser, without running a server, REPL, etc...
The main advantage of Javascript though is the freedom it gives to developers - you can be productive in it quickly, individual developers can get alot done with it in a short time, and it enables web apps to be created quickly.
Look at something like Firefox OS, how easy it is to script and develop for, and then you'll understand why JS is great.
For one, to get started, just open up a browser console, and have at it! No other language offers such a low barrier to entry.
Languages do not "offer" browsers. Browsers offer languages.
Javascripts flexibility is why you see emulators, 3D games and simulations, everything written in Javascript.
It's because people want to deploy to browsers and there are no alternatives.
Every language compiles to Javascript
Any language can be compiled to any other language if someone spends enough time on it. The reason people compile things to JavaScript is, again, because there are no alternatives.
The main advantage of Javascript though is the freedom it gives to developers
This sounds like something from Ministry of Truth in 1984. We're stuck with a single language, with no proper way to bypass it. The "alternatives" are ugly hacks that still revolve around the same language, have most of the same problems, then add some on top and make development tool-chains orders of magnitude more complex. How on earth this is freedom?
> Languages do no "offer" browsers. Browsers offer languages.
You misread? I said it offers a low barrier to entry. I'm well aware of Javascript's relation to the browser, or Dart's in Dartium as a counter example.
> It's because people want to deploy to browsers and there are no alternatives.
Flash? Java? C# (Silverlight)? Dart on Dartium? Native Client on Chrome? Some have came and went, some aren't catching on.
> This sounds like something from Ministry of Truth in 1984. We're stuck with a single language, with no proper way to bypass it. The "alternatives" are ugly hacks that still revolve around the same language, have most of the same problems, then add some on top and make development tool-chains orders of magnitude more complex. How on earth this is freedom?
So propose an alternative... Native Client in every browser perhaps? I wouldn't be opposed. Or is there another language you'd prefer? Dartium is here, you can test it today. https://www.dartlang.org/tools/dartium/
> This sounds like something from Ministry of Truth in 1984.
Freedom, as in low barrier to entry and shipping an app. And certainly more freedom than MS, Oracle or Apple offer with their solutions.
What platform makes distributing to users easier, and still free from corporate control?
For me, javascript is not a brilliant language designed and descended from heaven from God (or from Guido van Rossum), instead javascript is a political plattform.
It is currently the platform which is able to spread over the biggest range of devices because it evolved from an ongoing cooperation game.
This game isn't sane, it's not efficient and the result is a mess, but it's our mess for the time being.
I've yet to find a function, better, which can apply even a partial ordering on language designs.
A lot of the same arguments against Javascript are heaped on C as well. I think anyone has used these languages long enough and understand them deeply enough are more than aware of their short-comings. It hasn't stopped C programmers from writing the software that runs pretty much the entire world. Neither has it stopped Javascript programmers from making awesome things.
I think the argument that, X is a crappy language because it lets you do stupid things like Y, should be removed from the lexicon. I assume you've all seen the video of the wat talk and any Javascript programmer worth their salt has committed it to memory. If they haven't then they're either still new to the language or ignorant and could use some help. Maybe point them in Doug Crockford's direction.
There's no perfect defence against human error. It's why we write tests, static analyzers, linters and come up with practices like code review and prayer (hah!).
This was a really insightful response to a fairly typical neophyte language rant. I run a popular JavaScript meetup group and see a lot of JS devs trying to fit square pegs in round holes, struggling to make conceptual jumps from synchronous, O-O programming to a functional, continuation passing style. They gravitate to Promises or CoffeeScript, search endlessly for better control flow libraries, and try to write their own frameworks to make JS work like php/ruby/java, until eventually the light bulb goes on, and they get some of the concepts this article hit on. Thanks for posting.
"The built-in option to check an object’s ‘type’ is instanceof, which looks at the function an object was created with."
Nitpick, because I happen to be teaching myself the Javascript class system right now: instanceof examines an object's prototype inheritance, not its constructor. x instanceof Y if x inherits from Y.prototype, so it's possible to "sever" an object from its constructor by replacing the constructor's prototype property. Coming from a strongly typed language, this takes some getting used to!
Javascript is a tool. The fact that it runs in a browser and on a server means that communication between the client and the server in a Javascript-based web application becomes a lot simpler. If you know how to use the tool, it will serve you well.
You can find things to gripe about in every language you'll ever work with. Javascript is available. Use it and contribute to it's community, or don't. Griping is not contributing. It doesn't solve any problems.
If you think Javascript could use improvement, write a library to help solve a specific problem or contact emca and report your problem/issue/idea-for-improvement.
Basically just stop complaining and start working. If you are of the opinion that Javascript is a horrible language that is bound to make your project un-maintainable and disgusting regardless of your expertise then choose a different language.
I don't hate Java/Python/C#/C++ because I know I can realistically choose between them when building server, desktop and mobile software. I hate JavaScript because I am forced to use it for web clients. And transpilers are useless because I can't really use my high-level GUI (QT, GWT, WPF etc.) libraries. I spend enough time debugging raw JavaScript, I struggle to see how putting something on top of it will ease the pain.
That's, IMO, is another discussion. This JavaScript you talking about are written by programmers that often don't know JavaScript well and uses it as a little glue language on the client.
That's poorly written JavaScript.
On top of that, what I see missing on all this flamew.., err, discussion, is the difference between a more loose, small and open language and a more consistent, closed and regular one. Both feel a lot different. Comparing it in a given scenario may be valid, comparing they without any context at all feels like apples and oranges.
It actually is really important for people to point out how awful the current state of affairs is. If there isn't recognition of the problem, it will never be fixed. We need a standard browser bytecode, so multiple competing languages can exist and have the same access to the browser. As it stands now, people are using javascript as that bytecode, and writing decent language -> javascript compilers. Javascript is not well suited for this task.
JS might be a great language in isolation, but modern development or modern web development anyway.. in my experience wastes too many CPU cycles doing stuff that native applications were doing with higher performance years ago on some pentium 3..
Hopefully someone can solve the problem of distributing and updating native apps as smoothly as web apps (or websites, to be more accurate) with a minimal security impact and we can all go do some real 'modern' programming.
There are a few warts in javascript, but especially with "the good parts", it's really not that bad. Besides, it allows and encourages a lot of techniques which come from functional programming, which makes it a lot of fun for a functional programming hobbyist like me :)
How could one compare "exception handling" and "debugging"? They are two differed things. JS exceptions handling IS weak by design, no matter what debugger you are using. :)
ES6 is a 'future' development not 'modern' development language. It has not been released yet and it is unknown when it will be fully implemented by all mainstream browsers.
The single redeeming feature of JS is that it's implemented in all current browsers. If it wasn't for that fact I doubt anyone would have cared much.
It's just nowhere near as good as current alternatives for application development. Everything it can do another language can do better, except run in a browser - which is entirely out of control of the other languages so somewhat of a moot point.