> I’ve been writing web applications for over a decade and it’s utterly shocking how little JavaScript I know!
I'm glad he admits this, but then what exactly makes him qualified to opine on the language?
Look, Javascript is not great, and I'm perfectly open to the thesis that Node.js in particular is a Bad Thing -- I'm C# junkie, for crying out loud -- but supporting that thesis with a series of assertions from someone with little relevant knowledge is not terribly convincing.
> I'm glad he admits this, but then what exactly makes him qualified to opine on the language?
The fact that he has been using the language for a decade.
> Look, Javascript is not great, and I'm perfectly open to the thesis that Node.js in particular is a Bad Thing -- I'm C# junkie, for crying out loud -- but supporting that thesis with a series of assertions from someone with little relevant knowledge is not terribly convincing.
Why are you so worried about the person who states the argument? If he would claim that he is an expert who knows everything, would you just automatically believe him?
I personally would verify his claims regardless of who he is. If you just watch the referenced video, you might get an idea of where he is coming from.
> As most people well know, all programming languages have their faults. ... However, JavaScript is especially bad.
> I’ve been writing web applications for over a decade and it’s utterly shocking how little JavaScript I know!
I've noticed that most people slamming js either have zero or very little knowledge of the language itself as well as environments it works in.
Maybe, just maybe, it's worth learning a bit more about how and - more importantly - when js works.
I can only speak for myself, but I practically never run into any of those popular Javascript "gotchas" after using the language for so long. I've fallen into plenty of PHP traps, they tend to be a lot more subtle (especially that older one where a missing quote would error on the next line containing a quote), but JS's tend to be pretty avoidable, even in larger apps.
Theory: Javascript is bad not because of its syntax but because front-end/back-end is a new way of coding on the web and we have to redesign a lot of things (Json format, API, etc) in order to figure out the best way for it to work.
I am not saying I don't hate the syntax as much as the next person, but syntax is only so annoying.
The real issues come up with, for instance, execution contexts, callbacks etc because they are created for this new environment we find ourselves in.
(For those who say: hey, we have had client-servers for years, and we didn't face these issues, I think we have to start pointing to actual code, the problems, and the attempted solutions.)
I actually like JS syntax. It's pretty bland and, with const/let block scoping + await/async, it's easy to understand.
What sucks about JS is its lack of a type system, type coercion, and lack of a standard library. And those things really, really suck (and lead to terrible code). There's a reason MS, Google, and FB have all moved to static-typed JS (TypeScript, TypeScript, and Flow, respectively).
Well, the syntax has this one issue that I just cannot forgive: multiple exceptions to rules.
Like why should a beginner have to figure out when the semi-colon is optional, required, and to be avoided?
For anyone who says it is easy and then launches into an explanation, please compare your explanation to that in, say, Java and realize the error of your ways.
I don't know of a single instance where it's advised to omit a semicolon, nor one where a semicolon is strictly required. They are always optional. About all I've seen is Standard's guideline to put a semicolon before your entry point closure:
;(function() {
// .. snip
})()
And even that isn't required, it's just a function of another guideline: "Never start a line with (, [, or `." But still, that is only relevant to Standard, not to Javascript in general. It's completely self-enforced by deciding to use Standard if you want. I can't remember ever needing to put one of those characters at the start of a line outside that particular instance, anyway.
My thesis is that Javascript is bad because it was written in 10 days and got way too popular way too fast for Brendan Eich to have the leeway to fix anything with it.
Promises and/or async/await from day 0 would've helped a lot of people not code themselves into "callback hell".
But I really think the features that people consider bad have much more to do with the syntax: Lack of block scoping, lack of const, parseInt("072") === 58, eval, existence of the new() operator [0], semicolon insertion, function hoisting, == vs. ===, with statement.
[0] causes inexperienced devs to think JS is object-oriented when it is not
Someone who knows little JS writes a few bad words about it, without much detail, and provides alternatives he knows. He also attributes the fact other people don't write in languages he knows, to psychosis, despite not being a psychologist.
JS still puts the bread on my table. Not the perfect solution, but it is in high demand.
FE:
I'm surprised the OP didn't mention Elm [1]. Elm is not ( maybe yet ) popular enough for production uses ( at least outside of Silicon Valley ) and the better alternatives ( TypeScript, Flow ) are actually JS with sugar.
Frameworks
BE:
NodeJS is much more than JavaScript itself. It is quite easy and cost-effective. Because of NodeJS we have "full-stack developers" again ( I'm coming from Perl CGI Scripts - when everyone was "full-stack" back then ).
Go is super strict about it's formatting, so you practically have ES/JSLint in the compiler itself. I don't see a big problem in this sense.
> I won’t regurgitate the web only to say that a simple Google search will reveal JavaScript’s many internal inconsistencies and traps that literally make JavaScript a “digital minefield.”
Sorry, but I know the JS traps and I'm pretty well paid, because of that. I am not in psychosis and I love what
- Servers? Node.js
- Web apps? Browsers
- Cross-platform desktop apps? Electron
- Cross-platform mobile apps? React-Native
Will it deliver the best possible solutions (performance, size, etc.)? Probably not.
Will it deliver economically acceptable solutions? I think so.
Most of my customers don't even care which language I use, they just want their app idea implemented somehow. And many react positively when I say JavaScript, because they know a bunch of people developing in it, so when I get hit by a meteor, they don't have to find one of those rare Qt C++ gurus.
I disagree with the premise of the article. Javascript is what it is. I think at least most JS developers recognize that.
We use javascript because it does what no other programming language can do which is make the browser come alive. And we're done our best to minimize the displeasure of using javascript. I am not thrilled with the language, but I'm enthralled by what javascript can do.
To paraphrase Douglas Crockford unless you are going to revive Java applets you don't really have a choice if you want a dynamic web app.
The move to Node.js is a double edged sword. I like using Ruby on Rails and adding enough javascript to make the app more pleasant to use without constantly requiring a page reload. But the advantage of writing code on the server and the client in the same language is hard to pass up on. Trying to decide what to put which logic on the server versus on the client is a perpetual stress point.
While I agree there is some level of mass psychosis surrounding JavaScript, I think there is a lot more nuance to what's going on.
I don't think the onslaught of new frameworks and transpilers has been due to JavaScript's weaknesses as a language. I think it has been due to the rapidly changing landscape of _what users expect from web apps_ and the corresponding changes we need to make in the way we develop.
FRP is a great example: many of the recent shiny new toys have been different approaches to implementing this concept in the browser (React, Vue, Elm just to name a few). But this isn't just a trend because web developers are fickle, it's a trend because web applications are growing in size and complexity, and we're all sick and tired of implementing the same boilerplate to make the value of an input get assigned to some variable, or to make the changing of some variable trigger a change in the DOM.
I think there is some overlap, but in general conflating changing development practices with the problems of JS as a language, is drastically over-simplifying it.
Where I do see a psychosis is in the choice of JS as a configuration/build language. Systems like Gulp and Grunt make no sense to me. Why would you want a build script to be in a language with asynchronous I/O and callbacks? Build scripts are always one step at a time, feeding the result of one thing into another. JS just doesn't fit that kind of workload. I see that as a psychosis, and as the result of more junior devs wanting to choose a tool they are more familiar with, as opposed to the one that does the job better.
EDIT: Another example of a psychosis has been recently discussed on HN: the choice of embedded web browsers for implementing text editors[0]. Again: other than 'psychosis' mixed with the desire to pick a more familiar tool, what makes a web browser a good tool to build a text editor? Nothing!
> I don't think the onslaught of new frameworks and transpilers has been due to JavaScript's weaknesses as a language.
I whole-heartedly disagree. TypeScript, Flow, and Babel are all ways to address JavaScript's weaknesses. You could argue Babel is a result of out-dated browsers, of course. But fragmentation of targets is certainly an issue of the language -- earlier versions didn't have to be so poorly designed.
Would we have all these transpilers if we were using a fully-formed, general-purpose language for the web from the start? No. If JS had a type system, there would be no TypeScript, Flow, NativeScript, PureScript, etc. If JS had a sane way to handle parallelism from the beginning, Babel wouldn't be nearly as useful.
Yes, it's true that JavaScript wasn't designed for what it's being used for now. That doesn't mean it's a good language (or ever was).
As a language, JS is what it is - therefore you can use or ignore parts of it, target it from a transpiler, etc. It's Node, its de-facto execution environment on the server side, that's the travesty - a hardly-glorified version of the browser's execution environment. Sure, a well-designed Node app. is better than your average long-running, thread-holding CGI script from 1998, but there have been servers for ages that can do async thread sharing/pooling like Node (and with proper language support, if you want it) but don't force you into this model if your task happens to require true task parallelism rather simple asynchrony, which require hacks that range from just ugly to truly horrid.
The designer/engineer identity and personality disconnects are definitely a big part of the story of Javascript in the last five years.
SF (design) took over as the bleeding edge when Javascript finally burst on the scene, and Palo Alto (engineering) faded.
The interesting thing to me is the amount of identitarian-style thinking that I see around the arguments in technology (macs, linux, javascript, etc.) where it is obvious that in-group/out-group factors nearly completely dominate discussions, rather than technical issues and trade offs.
I don't think so. PHP has batteries included, yet there's bazillion of frameworks too. People just like to create their own stuff, doing ever smaller improvements, or disimprovements if they overengineer because of being dogmatic about OOP, patterns, etc.
Libraries you can't avoid. There will be always something missing that someone needs.
No, if you're using a version of Node released in the last few years. The most recent versions support async/await syntax in addition to promises, which fix callback hell.
I'm glad he admits this, but then what exactly makes him qualified to opine on the language?
Look, Javascript is not great, and I'm perfectly open to the thesis that Node.js in particular is a Bad Thing -- I'm C# junkie, for crying out loud -- but supporting that thesis with a series of assertions from someone with little relevant knowledge is not terribly convincing.