Four Solutions to the JavaScript Problem
short-sharp.blogspot.com
short-sharp.blogspot.com
You don't like JavaScript. We get it. The number of people who don't like JavaScript are as "well-documented and well-understood" as your problems with the language, as are the solutions you mentioned (use a subset of JavaScript or something that compiles to it).
I'm more than happy to read novel criticisms or novel ways to improve the language, but the ecosystem really doesn't need yet another blog post rehashing common knowledge (anyone who cares knows about The Good Parts, CoffeeScript, and GWT) and beating the "JavaScript sucks" horse.
The hate on JavaScript "horse" is past being dead. Maybe we can start a Javascript is ok/has good parts but is here to stay "horse"!?
To me, removing javascript in its current form from the web is in the same class of insurmountable issues. To "Solve" the issue action needs to be taken by literally everyone who is involved in the web. To do that the first step to that action starts with admitting there is a problem.
I'm in favor of beating the dead horse, because every once in a while, i see it try to breath again.
JavaScript is very usable by most people, and when you understand it, it gets a lot better. Since node.js/io.js with the likes of browserify you get a pretty nice module system as close to in the box as you can get. With es6/7 and things like BabelJS you get a lot of modern features as well which makes functional composition really easy.
I understand the visceral hatred of JS... I simply don't agree with it. There are a few odd corner cases that are fairly easy to understand and avoid... The problem is that some developers want JS to behave like language X. They have TypeScript which is becoming similar to ES4/C#, there's coffeescript which brings in hints of ruby and python... There's closure and a host of other options too.
In the end, it comes down to taste... I try to stay closer to JS/ES proper, and simply avoid Prototypes for the most part in code I write. I find that function libraries that operate against plain object instances are easier to reason about... treating data as idempotent (even without actually cloning objects) helps too.
JavaScript really has some beautify functionality to it, and I've felt this way for a very long time (back in the 90's even). I think it's when people try to bend JS, or the browser DOM to their will that they get burned... as opposed to actually learning how to use JS.
It's not the best for every use case... but it's a pretty good option for many of them.
There might be a fifth solution: learn JavaScript. Its not actually that hard to be productive - I realize mastery always takes time and effort, but its pretty quick to get started and be able to write some decent stuff.
I don't primarily code in JS but I keep it near the top of my toolbox. I'm not up to date with the latest and greatest (which I'm sure it getting better and better) but even in 2011 when I had the opportunity to do some stuff with node, I was pretty satisfied with what the language provided. Some of the syntax was a little verbose, but I can type pretty fast so no sweat.
I wouldn't be surprised if Crockford's jslint rules are not that relevant anymore... around 2008-2009 when I did more web stuff I used to make sure all my scripts could pass with `browser = true && global jQuery` (or whatever the format for the hint was), but even at that time much of that advice was starting to seem irrelevant.
Most of it comes down to opinion... I like comma-first and a few other differences from the norm. It's easy enough to change eslint to suit your needs. I'm using BableJS lately also, as even io.js options are still a bit incomplete by comparison. Modern (ES6/7) JavaScript is really nice to use.
Bjarne Stroustrup's quote seems more and more relevant to me every time I hear complaints about JavaScript.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses."
Edit: Well this is hilarious. I started writing this comment with no comments on the page and by the time I submitted it several posts seem to complaining about the constant complaints about JavaScript. Great minds think alike or JS devs are super-defensive?
I guess it never clicked for me since whenever I come across it I usually also have access to a stack trace or that line number which threw the error.
I think you might be nitpicking... JavaScript is perfectly usable as is. They even ship a js interpreter with OpenJDK since 1.6... why bother if Java is so much better and easier to use? And also conflating a bug in Chrome with a language deficiency seems fallacious.
Because
> And also conflating a bug in Chrome with a language deficiency seems fallacious.
It's not a Chrome bug, it's a missing feature in every existing Javascript implementation that only Chrome is bothering to add (though hopefully other implementers will follow suit shortly)
(Also because certain libraries, in particular for async, simply don't exist for Java because the sync version is "good enough")
High level languages should have either lightweight objects/dictionaries or tuples (my preference is for both, but you can get by with just one). Java lacks both to this day.
And even "big flaw" is a pretty big understatement about the impact of higher order functions.
If you use a module/builder system in JS, you can do composition and testing that most other languages simply don't hold a candle to. Including Java/C# and plenty of others. If you include Browserify+BabelJS it gets better still.
Just because you have trouble wrapping your head around the concept of modules or object composition without classes doesn't mean everyone lacks that skillset.
/rant
I do work in a functional mindset. I still find that I need them often, for cases where one case needs to be handled differently from others, which is a very common business requirement. Something like typeclass deriving can help, but javascript doesn't have that.
> doing unit testing in JS doesn't require the mental spaghetti of interfaces or IoC/DI that it does in strongly typed languages.
You don't have to do it that way if you don't want to - even in humble java it's trivial to mock any object or none if that's what you want. I like having explicit interfaces - they're what make it possible to maintain big codebases.
Writing larger applications in a team isn't impossible with JavaScript. It's just needlessly difficult.
Well, even if it's just me, after a few hundred lines of JS, I really start to miss proper tooling.
ES6 did at least add some structure and tooling hooks with classes, modules, default parameters, and named parameters (via destructuring). However, it's nowhere near the kind of tooling you get with TypeScript or Dart.
Optional types are really handy. Just add some types to the signatures of your functions and you get massive tooling benefits (and basic documentation).
I find that people tend to have a hammer (be it ent-lib for .Net, or any number of other tools) and like to see everything as a nail. When you stop trying to force JS in a class system box, it becomes much nicer to work with.
The web needs a bytecode language that other languages can compile to. Some people say JavaScript can be that bytecode, and asm.js is a big step in that direction, but for the web to grow to its full potential developers need the freedom to express their ideas in the languages that suit them best.
That's...silly, I guess?
"The JavaScript Problem is two fold: JavaScript sucks, but we need JavaScript."
Can we just got over this JavaScript sucks issue. We get it. There are a lot of people who hate JavaScript but we know the issues so start using JS the proper way.
Reminds me of when I moved from PHP to Ruby & Python reading arguments that people should just shut up about the 'minor' problems PHP has and that it isn't going anywhere.
Well JavaScript _really_ isn't going anywhere. It is here to stay. But that doesn't mean one should stop complaining about where JavaScript falls short.
There are multiple angles to get out of this mess:
* Local optimization (trying to fix the things that can be fixed and not introducing new problems: very hard, very slow process, think quicksand).
* Global optimization (Dart, ClojureScript, Elm, GWT. Ambitious compile-to-js languages that give you a ton by moving away from what makes JavaScript JavaScript)
* And something in between like compile-to-js languages that stay closer to JavaScript like CoffeeScript, TypeScript that add to it and/or retract stuff.
The fascinating thing here imho is that especially the ambitious approaches to getting us out of the mess we're in lead to faster local improvements (here just some of them) …
* SIMD support: Dart nudged JavaScript to add SIMD support, John McCutchan of the Dart team even worked on that
* Classes: Dart, TypeScript, CoffeeScript
* Briefer, more expressive syntax: CoffeeScript, Dart, TypeScript
* Optional types: Dart, TypeScript, …
* VM Performance: Dart
JavaScript got better as a language as well as a compilation target, especially in the last few months. This is great for all of us. It happened and happens because people are not satisfied with the status quo and don't shut up about it and do what they can to go beyond what's 'good enough'.
The day it becomes unacceptable to criticise the status quo is the day innovation dies. I hope the JavaScript community at large is far away from that mindset.
I don't take issue with the OP criticizing JavaScript - I take issues with the article for lacking substance and with the 20 upvoters who signaled it would be a good use of time to read.
It seems increasingly as I get older programming it is more an exercise in patience. If you want to build something useful today you need to use today's tools regardless of how good or bad they are.
The mistake some people make I think is to norm this and accept bad tooling as a matter of course.
That I suppose is the core of the "I hate JS" arguments, to get it to do what you want, it has a slightly unintuitive non-syntactical way of solving it's problems. That of course, is only the case if you intend to replicate the programming styles the syntax of other languages gives you. I don't think you should. And now with ES6, we have those other styles in our syntax, so it's even less of a problem. Hate on JS all you want, but it's probably not so amenable to you because you're using a metal file when you really need a belt sander, close but not quite right.
You can create a number of stand-alone functions that take an object that is operated against as a parameter and return a value, or modified object. You can now test these independent functions as modules without a lot of distractions that come from side effects and state. With that in place you can bind those functions into a composed object (state), and use that in the rest of your application. You have composition, encapsulation and testable code that is just plain difficult to reason about when you are using Class-based inheritance and trying to test against it.
I actually love JS... it has its' quirks, but I find the flexibility it offers to exceed what most other languages offer for most tasks. Using small function libraries and modules, I find that I can orchestrate much larger operations far more easily than can be done with other systems (usually). All of that said, I also love C#, and use it very differently.
People should stop trying to walk in water, and just swim.
Or do you mean dynamic typing?
The only real gotcha in validation is when you want something that is a numeric-string or a number to be a number, and anything else to be a null. Outside of that case, I find that dealing with data migrations/translations in JS is FAR better in practice than most of the options I've used. Especially when you compare to the likes of say C, C#, Java etc... Yes, you can use strong XML validation, but it tends to produce a lot of errors that are recoverable in JS.