> I’ve been writing web applications for over a decade and it’s utterly shocking how little JavaScript I know!<p>I'm glad he admits this, but then what exactly makes him qualified to opine on the language?<p>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.
> As most people well know, all programming languages have their faults. ... However, JavaScript is especially bad.<p>> I’ve been writing web applications for over a decade and it’s utterly shocking how little JavaScript I know!<p>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.
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.<p>I am not saying I don't hate the syntax as much as the next person, but syntax is only so annoying.<p>The real issues come up with, for instance, execution contexts, callbacks etc because they are created for this new environment we find ourselves in.<p>(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.)
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.<p>FE:<p>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.<p>Frameworks<p>BE:<p>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 ).<p>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.<p>> 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.”<p>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<p>1: <a href="http://elm-lang.org/examples/hello-html" rel="nofollow">http://elm-lang.org/examples/hello-html</a>
I disagree with the premise of the article. Javascript is what it is. I think at least most JS developers recognize that.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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!<p>[0] <a href="https://news.ycombinator.com/item?id=13940014" rel="nofollow">https://news.ycombinator.com/item?id=13940014</a>
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 <i>force</i> 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.<p>SF (design) took over as the bleeding edge when Javascript finally burst on the scene, and Palo Alto (engineering) faded.<p>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.
JavaScript has many challenges, but I think the biggest by far is the lack of "batteries included" standard libraries.<p>Without those, ecosystem fills the vacuum with a large, evolving mix of overlapping libraries that don't interoperate.<p>How often have you considered library X, but then found it doesn't work with your project's other libraries and frameworks?
As someone who doesn't use Node: Do most of these arguments apply to Node? (Silent failures, callback hell, weak typing brokenness).<p>I acknowledge that most of these are very bad in the browser, although I have good things to say about Typescript.