JavaScript isn't ever going away, is it? Will JavaScript ever be removed from programming, ever? Is there any hope for this at all? |
JavaScript isn't ever going away, is it? Will JavaScript ever be removed from programming, ever? Is there any hope for this at all? |
Is it because you're mixing it up with the DOM, especially the DOM of Internet Explorer of yesteryear? If so, scripting IE 6's DOM with Python would have been just as perilous.
Is it because you're mixing it up with Node.js, and its asynchronous complexity? If so, JavaScript doesn't have to work that way. And other languages could have been used the same way. Say, Node.py or Node.rb. Conversely, JavaScript could be framed in a normal, FastCGI apparatus, where everything runs more or less straightforwardly.
Is it because you're mixing it up with the messiness of NPM? See above.
Is it because JavaScript is dynamically typed, or because it has some other characteristic that seems less serious than languages like C, Java, or Go? If so, why not the same hatred for Python, Ruby, Perl, and Lua?
I myself like JavaScript's syntax more than all of the other scripting languages. I think the syntax for object literals and array literals is pleasantly terse. So is the dot notation for attributes. Combine that with how functions are first class, and you can chain them with dots instead of nesting them in parentheses. I like the new arrow syntax for functions, making the code even simpler.
I don't hate JavaScript, but I do dislike it. After advancing in my career and becoming a back end engineer I strongly prefer the type-safety of strongly typed, typically compiled, languages.
I've worked in large dynamically typed code bases and I've worked in large strongly typed code bases. I have loathed every refactor I have had to do in dynamically typed languages. I just did a big one for a Python code base and I caught more issues and dependencies using grep and emacs than using the IDE and PyCharm. I have about 25 sizeable unit tests for this code base just to check flow control and dumb things like typos. I wouldn't need these unit tests in a compiled language.
JavaScript is the most popular language in the world. It's going to get a lot of hate and love. You contend that it gets disproportionate hate compared to Python and Ruby, but I disagree. I dislike all dynamically typed languages (save bash), and I think many people feel the same way. I honestly fail to see what they buy me.
If it's short and sweet I'll do it in bash, if it's any longer than what bash can handle I'll write the few extra lines of code in Go, for its safety and performance.
If I have to write browser code, I sigh and get on with my life.
http://stackoverflow.com/questions/816071/prototype-based-vs...
1. It almost could have been. By this, I mean: JavaScript inherited a lot from functional programming. It's impossible to know how much of that was sacrificed in its original design, but its final design (curly braces and dots) is not just a syntactic nightmare, it's downright hostile to JS's functional roots. (See recent posts about whether a given JS function is "pure". Those are perfectly innocent functions, but you cannot provide any guarantees about whether a JS function mutates state.)
2. It's not just dynamically typed. It's impossibly typed. There are code golf games going around ("return true to win") which demonstrate just how esoteric its type system is. One of the reasons (though not often talked about) that the Node ecosystem is so full of hilarious micro-libraries is because you genuinely cannot write a general purpose library of any larger scope in JavaScript that's provably correct. There are too many sources of bad inputs, and too many ways for those to compound, to know that you've written software that does what it says it does under every circumstance.
Let's be clear. Every dynamic language has problems. I can construct comical failures in Python (a language I don't even know that well!). But that leads us to...
3. It is impossible to avoid the hackery of the JavaScript ecosystems. Because the browser environment is broken, and because Node is so low-level, and because the JS universe is relatively welcoming in so many ways to people who don't know they're reinventing the wheel. It's astonishing that the Promise pattern took so long to solidify. It's not really astonishing that sugar around it (async/await) is being designed in completely pathological ways (top-level await).
4. Some of ES6/ES7/ESnext/what is it even called now? is just provably wrong. Do not introduce language features that do misleading things! The `let` keyword denotes immutability everywhere else. Not only does JS violate this, but it has no other immutability story. Arrow functions are not just a simpler syntax for functions, they require developers to know two very complicated sets of rules for `this`!
Side-note: I also used to write PHP full time. JS is doing all the things PHP was doing when I was lucky enough to bail: cargo culting weird stuff that doesn't even make sense. For PHP, it was "how can we Java this up without even approaching Java's performance, breadth of application, or even its data structures?" For JavaScript, it's... decorators? Really? Because JS needs more indirection?
5. Even JS devs don't write JS anymore. You gotta know at least one transpiler and at least one package manager. Good luck if you want to work on another project, even at the same company. Good luck if you want to use a canonical module system. Good luck if you want to know what `import` even means (there's a config file somewhere that says what happens if you import a CSS file).
6. But seriously. Types. Immutability. It's not even addressing these things. When it tries, it's making them comically difficult. `Object.create`, `Object.defineProperty`. Why make it as hard as possible to see what a thing is and how it behaves? How many layers of indirection do we need?
And another redundant side-note: try asking a JS dev in a code review to define an obvious type with a constructor function. They'll look at you like you're crazy. It's idiomatic to just attach random ad hoc properties to some anonymous object to infer what the thing is. What happens when you want to compose them? SHRUG.
- - -
It's not like JS is the worst language I've ever written (that would definitely be PHP, thankfully I never wrote VB or ColdFusion). I'm sorry if I've insulted anyone ranting about this, I really don't mean to. You gotta live with the ecosystem you're in.
I am not super fond of the languages I work in, either. Python has a whole lot of the same root problems underlying the stuff I talked about above. Clojure(Script) has most of its immutability story straight, but basically nothing else. (Well. It's got syntax going for it.)
But yeah. JS has problems. They're probably not fixable. That's why everyone (even JS devs!) is compiling applications of any serious complexity to it.
JavaScript, especially in its most recent iterations, is a decent language with useful properties (non-blocking; can be used purely functionally and in an object-oriented or procedural manner) and a fast runtime. It's especially suitable to the task it's mostly used for: Web app development.
I can hardly think of any programming language that'd be more appropriate in that context right now.
The only real downside is that JavaScript isn't a typed language and there are options like TypeScript that while perhaps not completely solving that particular problem at least alleviate it to a large extent. Who knows? Maybe, the next version of JavaScript will provide a type system similar to TypeScript, which given the latter's adoption and support by several large companies isn't entirely unlikely.
Over a span of about 12 years it's gone from being my most hated language to my most loved. So I hope it sticks around.
Won't go into details but JSLint, Crockford, Node, ES 5, 6 all really helped.
No, it was once dominant in a particular niche -- it was enterprise's Java long before Java was -- but it was never the "be-all-end-all" of programming languages.