JavaScript's world domination
medium.com
medium.com
And yet everyone turns Beta vs VHS into a sob story about how the best doesn't always win, instead of figuring out the real lesson: know what your customers want and give it to them.
(Same general idea though.)
Based on what people tend to complain about, some languages have more should-be-avoided parts than others. I guess no language is perfect... but that is so obvious that it doesn't need to be mentioned. Yeah, no language is perfect. But it's still interesting to see which ones are the least "perfect".
I don't get this tendency to want to muddy the waters with appeals to "nothing is perfect". Nothing is perfect, but some things sure seem to suck 5 times or more than other things.
(For that matter - it actually does seem like there are languages where you at least don't have to actively avoid parts of the language. Maybe they're not the best or currently the ones which are recommended, but it's not like people say that you should avoid them because they might trip you up in a weird way.)
That's its only distinguishing or redeeming feature I can see. If you had a free hand to choose, would you ever want JavaScript?
Oh, I imagine my copy of Crockford's "The Good Parts" is more well thumbed than most, and I do my utmost best to keep it all clean, but having a great time I am not.
It basically contains its entire history, from a PHP-like hack job that started it to the very elegant ES6/7. It's probably one of the few languages that expose their whole fossil record.
[1] A standard complaint deserves a standard response.
Some Python programmers complain about Python 2.
Some Python programmers complain about Python 3.
Everybody complains about the GIL.
Were only that effort spent on eradicating the old legacy libraries!
You can not "eradicate old legacy libraries" on whim - this stuff is out there. It is used by software out there. Software that would break if things like that would be removed. You can't just rip out and change parts of it at whim. You have to work around problems - at least until they wane in popularity and slowly die out. Evolution, rather then revolution - as stated in the article. That is exactly what TC39 is doing when they are improving on the standard and JavaScript itself.
Case in point: Array.prototype.values was a proposed feature - returning an iterator for the values in an array[1]. The feature was introduced and had to be backed out at least twice[2] because widely used web frameworks (in this case, Sencha) used the attribute "values" on arrays and webapps broke as the method was added to the Array prototype. And this wasn't the first case.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]: https://esdiscuss.org/topic/array-prototype-values-breaks-th...
We get to strongly push for new language features, or we get to strongly push for backwards compatibility.
If we elect to do both blindly and without forethought, as the JS community seems to be doing (having learned from the C++, evidently), we are going to run into these things over and over again.
And frankly, a lot of the legacy code and terrible hacks on the Web deserve to be broken, noticed, and remove/updated. Hacking prototypes (as Sencha did here) is something they shouldn't have done in the first place.
I've been a fan of JS since pretty early on... the DOM differences between IE and NN were really horrible to deal with in the v4 browser days, and until jQuery didn't start to get much better really, where today you really don't need jQuery. It's an evolution here... If you're willing to use transpilers you can go anywhere you like... from BabelJS to ClosureScript, TypeScript, CoffeeScript or others... you can get the style you like.
npm + browserify (or webpack) have made developing modern web applications a dream compared to the past.
Sounds like almost every successful startup, too.
Starting out as just "good enough" is fine. Improvements will happen over time. It is short-sighted to look at where we are today and believe it to be the end of the story.
JavaScript is a great language with a dark past and it suffers from its legacy. I've programmed in C/C++, C#, Java, AVR assembly, PHP, ActionScript and Python among others and I would not hesitate to say that JavaScript is my favourite.
Why are there so many NPM modules? - Because people who know JavaScript love it. I'm yet to see the same kind of passion in any other programming community.
Yes, it has some gotchas, but so does every other language.
When used correctly, function closures are awesome! REALLY awesome. I pity the poor, poor fools who misuse them and end up with callback hell.
People mention 'callback hell' a lot, but no one talks about callback heaven.
Although a shorter function syntax with default-return on everything would make it a lot nicer (and more similar to LISP).
Personally, I much, much prefer working in Clojurescript to Javascript. Once my dev environment is setup, and I am rolling, there is not much inconvenience or build delays at all. My setup is editing in IntelliJ (both Clojure and Clojurescript), one clojure repl, and one lein autobuild task to keep the generated Javascript up to date, given about a one second delay.
Javascript is not such a bad language, I use it directly when doing meteor.js development, but I think the future is better languages like Clojure, Haskell, Scala, etc. transpiling to Javascript.
All that said, that was a nice article!
javascript-to-java and javascript-to-obj-c transpiling
I'm fully aware of the existense of alternatives out there like PhoneGap, Ionic ..etc but I'm envisioning a future where you could write in javascript mostly everything you could do in other languages and transpilers take care of the rest.
Cross platform UI has AFAICT never worked, so you won't be able to reuse code from one platform on another, or is that what you intend to do? In that case you could still transpile from either Java or Swift...
So they're half way in their make believe
Honestly I think this has been the 'future' for a long time now, and I still don't see it happening anytime soon. Clojurescript as a language was announced in mid 2011, NodeJS came on the seen in late 2009. Both were languages never or barely used in their respective domains (server vs client side), but NodeJS has clearly had way more adoption on the server side then Clojurescript ever has had on the client.
Unless we get significant browser buy in for other languages (aka not just Chrome) and much better tooling I don't think any transpiled language is ever going to go beyond the minor niches they fill. And I say all this as a huge Scala fanboy, having used it for years in a professional way, and being very interested in ScalaJS. There simply isn't a language that has the buy in and following Javascript has been able to develop.
Say what you will about the relative inelegance of jQuery, at the time of its release it certainly made JS--particularly DOM manipulation and AJAX--very accessible and cross-browser compliant. It definitely made articles like this seem quaint. [1][2]
At about the time of jQuery's release, Flash development was a viable alternative for smaller sites. I was doing bits and pieces of freelance around 2007 and after the iPhone came out, even my least tech-saavy clients stopped talking about Flash.
Pretty sure that these two bits made it so that every front end dev/ designer in the world was at least passably decent at Javascript by the time Node arrived.
[1] http://boxesandarrows.com/htmls-time-is-over-lets-move-on/ [2] Also, Mootools and Prototype and YUI etc, but jQuery is the one that became ubiquitous
Building tools and extending what is currently made available to developers by the platform - all this is in our very natures as developers. We did that even in the early days, when low-level primitives were mostly missing to support us in that work.
Jake Archibald explains this in a comment on Nat Duca's post over at G+[1] - give developers some primitives; see what they do with them - then distill it and create high-performance features out of what now you already know there is a market for. TC39 works on this basic principle (everybody whines about types in JavaScript - TypeScript might be the JavaScript's jQuery here, paving the way for some distilled type system in JS (or SoundScript. or anything else that's out there).
*
As for Apple - I am siding with Peter-Paul Koch on this[2] - Apple had some quite a few good deeds in favor of the web, but that was a long time ago. Nowadays it just seems to be protecting its walled garden that is native apps & the related ecosystem - certainly not giving a whole lot about making the web a better place (or devs, for that matter). The Pointer Events fiasco is a perfect reminder to all this.
For any good Apple has did to the web, the surely made equal bad so the scales are (IMHO, at most) 50-50 here.
[1]: https://plus.google.com/u/0/+NatDuca/posts/De8Bv6F4fyB
[2]: http://www.quirksmode.org/blog/archives/2015/02/tired_of_saf...
I keep seeing variations on this statement, and I have never figured it out. What, exactly, is it about JavaScript that makes it particularly appropriate for this paradigm?
The way I see it, the only abstraction JS provides that helps with this is first class functions, which are also present (and often richer and more robust) in many other languages.
It's not that Javascript is especially suited to this model, but thanks to the browser, it was already the most used implementation of this model.
But it was the broad availability of mindshare of those developers who at least knew some JS that really kicked it over the top, given JS as a DSL for I/O bound applications.
Underscore, Flux, promises.js, Async, Angular, Node fibers, Step...
How much is all this abstraction costing us, both in terms of computation time and developer time (both writing and debugging)?
We're in something of a JS framework boom (or hell, if you wish) right now. These people are developing as if their shit libraries won't exist in 3 years. Hence, the total lack of documentation and ongoing maintenance from so many of them. I've already had to maintain code that used abandoned JS frameworks. I'm a little scared of what's around the corner here...
Python has first class functions, but not anonymous functions, since lambdas aren't full functions.
And Python doesn't have closures, because you have to use "global" or "nonlocal" (in Python 3) to assign a a variable in an enclosing scope.
These features let you write concurrent state machines in JS without explicit state -- you basically use the stack as state.
Python was pretty early in terms of event loop programming for interpreted languages -- asyncore in the stdlib, and Twisted. But I agree that the node.js style is nicer than asyncore, Twisted, or Tornado. I prefer coroutines over state machines, but if you're going to write state machines, than doing it with anonymous closures is nicer than doing it "manually" with classes and so forth.
Tcl was even earlier, but Tcl is pretty foreign to most people, and was more of an embedded language than a scripting language. Pretty sure Tcl has full anonymous closures, but it is a bizarre language in some other ways.
I haven't seen the event loop style in Perl but I think you can do it. If someone has an example I'd like to see it. To me, Perl only barely qualified as a real programming language because you can't even name your function params? At least when I used it, which was over 10 years ago.
Python isn't an exception among languages that people in industry actually use.
For "production grade" server software, which is driving the newfound interest in concurrency, the following languages cover 99% of code written in the last 20 years: C/C++/Java/PHP/Perl/Python/Ruby and the Microsoft Stack (C#, VB).
None of them have anonymous closures. (C# might, but it's also newer, and it's not the the prevailing style of concurrency in any case.)
This is basically JavaScript's Scheme heritage showing through. Anonymous closures are old hat for people who went through a CS program teaching Lisp, but they're not by any means standard in industry.
One of the main reasons that none of the languages needed this feature is because the predominant paradigm for concurrency for the last 2 decades was threading, not state machines and callbacks.
Perl and PHP both have closures. In fact, Perl is closer to Scheme/Lisp than most languages (at least Perl doesn't screw up scoping like JavaScript, replace first-class functions with second-class-bastardizations like Ruby, or do whatever Python thinks it's doing with lambda... ugh)
#!/usr/bin/node
function main() {
var a = 1;
console.log(a);
// named closure
function foo() {
a = a + 1;
}
foo();
console.log(a);
// anonymous closure
(function() {
a = a + 1;
})();
console.log(a);
}
main();> There is no such thing as an "anonymous closure". There are only anonymous functions which may or may not create a closure.
Which is exactly what you did: calling an anonymous function which happens to create a closure over variable `a`.
And that's why Python supports `asyncio` (not to be confused with `asyncore` which is obsolete). So I prefer:
sock = yield from connect('localhost', 7942)
msg = yield from read_message(sock)
print(msg)
connect('localhost', 7942, function(sock) {
read_message(sock, function(msg)) {
console.log(msg);
});
});
`asyncio` is not only easier to use than the traditional "manual" state machines with classes, but also much faster than something like `Twisted`. In my crappy local benchmark[1], it easily beat `Twisted` in a considerable margin. That may be because of the flaws in my test code, but still their performance is on par. I see no points in relying on callback hell, at least in Python, except the lack of the libraries that support asyncio, which makes me a little bit sad.
Part of the reason for stagnation was because you really need new language features -- i.e. yield/send, yield from, etc. JavaScript already had the necessary language features for its concurrency model.
Don't despair the future is bright :)
The different syntax also prevents you from creating functions that can be reused by both sync and async code.
The big thing promises and other callback-based control flow libraries do is that they fix exception handling in async code (its a PITA to add error handlers in every callback when writing async code by hand). They also let you avoid some of the awkward "pyramid of doom" nesting but thats not really killer feature because you can also achieve that by using tons of named functions.
The required bits are in place... alternatively you can use co/koa which uses generators along with yeilding promises to act in a similar fashion.. it does work pretty well, and will only get better.
Lua was quite pleasant to work with in this context!
async read(connect, readMessage, print) {
const sock = await connect('localhost', 7942),
msg = await readMessage(sock);
print(msg);
}V8.
And it's a pretty powerful language. C-like syntax (familiar), Lisp-like (powerful/flexible), it's everywhere and it's fast (thanks to V8). Really, if it weren't for Chrome, Node.js wouldn't be a thing, and JavaScript wouldn't be ruling the world.
It's still possible v8 somehow sparked those other JITs, if before it was public the developers of WebKit and Gecko learned of v8 and stepped up their game. But, I don't know if that's true or not.
Anyhow, it's an impressive achievement that people still mention v8 as the reason JavaScript is fast, when it isn't the fastest today, and wasn't the first to be fast historically. Although, it is certainly a worthy VM, just one among several.
To me, the node story seems to boil down to "V8 was a readily-available fast runtime and people who already knew JS flocked to it" — which is fair enough, but hardly an argument for how appropriate JS is, as a language, for this sort of programming model.
That's basically all there is to a language's success. We like to debate syntax and closures and continuations and type systems and immutability and concurrency models on programming language message boards, but realistically, nobody cares. The two questions they have when they encounter a new language are "Can I learn this in a weekend?" and "Can I build cool things that other people would actually want to use?"
If you look at the history of programming technologies that have "won", the list includes C++, Java, Javascript, PHP, C, Objective-C, and to some extent Perl, Python and Ruby. The first 4 of those are terrible from a language-design standpoint, but the two things they all had in common were a readily-available reasonably-fast runtime (except PHP, and that was "fast enough" for the things people use it for), and a familiar syntax. C, PHP, Javascript, and Objective-C also had the benefit of being the "native" language for a major application platform, which seems to be the other major critical success factor for a new language.
There is a possibility that this viewpoint doesn't leave any room for: the possibility that languages make nearly no difference. Perhaps people are savvy, and interested in more complex things, but the various languages and platforms don't bring any concrete value. Instead of being a function of how widely-ranging people's interests are, it's instead a question of whether anyone is actually making real tracks away from a center, a center whose nebulous nature is only permitting the forging of false distinctions in.
Rather than marking time by languages, perhaps it's more interesting to mark what we focused our language use on?
You can make smart, high level languages like Haskel or Ceylon, but people will generally prefer dumb, easy to learn languages like Basic, PHP or JavaScript, despites their limitations.
Result: instead of making a nice car, well designed and looking good, they put big wheels and powerful engine on soap box cars! :-)
And I'm not a big fan of that theory that JS is Lisp-like. The only thing thats particularly lispy about JS is the first class function and even then they are a bit fucked up because of the wonky function-local scoping rules and the "this" keyword.
It's showing that you've been burned by these magical creatures. It takes time and effort to get used to mastering these awkward concepts
Actually, if you don't know how ((this)) works in different context, you can't call yourself a good js developer.
function handleRequest(req)
data = db.fetch("user")
return render("template.html", {user=data})
In db.fetch it uses the "yield" keyword that would tell Lua it is about to do an async operation it should wait till it finish before continue running Lua code, meanwhile run something else instead, making it non-blocking and you can run many of these Lua programs at once on a single thread, all of them concurrently.
function mapList(xs, f)
local ys = {}
for i=1,#xs do
ys[i] = f(xs[i])
end
return ys
end
mapList({10, 20, 30}, function(x)
return db.fetch(x)
end)
I have plans to write dbslayer like "access DB over REST" service as a companion to Luaw so that it can use any and all databases that have JDBC drivers available without having to write non-blocking driver specially for each new database. This kind of arrangement where DB connection pooling is abstracted out of application server itself has other advantages related to auto-scaling in cloud and red/black or "flip" code pushes at the cost of slightly more complex deployment.
All depends on how much spare time I actually get :(
app.use(function *(){
var db = yeild getDbConnection();
var data = db.query("procname", this.request.query.param);
this.body = JSON.stringify(data);
});
Just choose a decent abstraction for callbacks. I prefer promises, but async.js does a good job as well.
The `flatMap` function on a Future in scala might be built into the language, but it is implemented and scala and not significantly different (in my mind), to Bluebird being implemented in javascript.
Every time I use JavaScript I imagine how good life could have been were it Scheme. Every time I have to use JSON I imagine how great life would have been were we using canonical S-expressions[1] instead. There's one good thing—and only one good thing—about JavaScript: it's incredibly well-deployed. As another commenter mentioned, JavaScript is an object lesson in path dependency.
In many ways, it's appropriate that it has 'Java' in the name: it's popular, but it's ugly. There are better languages; indeed, nearly every other non-Turing-tarpit language is better than either Java or JavaScript: Lua, Lisp, TCL, Python, Rebol, Erlang.
Devs with experience writing interactions with the DOM had already convinced themselves that callbacks nested ten deep was a totes OK way to write code, "releasing Zalgo" and all.
In other languages, you could use libuv or tornado or aio or whatever, but it's like throwing away the entire ecosystem and using an obscure language anyway.
If you're trying to do non-blocking async stuff in other languages, you have to hope/check that none of your code and none of your dependencies try to do blocking I/O. (Unless you're using something that does async under the covers like haskell or go)
Ajax was great when IE rolled it out all by themselves. It first might seem like a skunkworks like ActiveX if you didn't know better. Give it a few years' time, coordination and cooperation, and now we've got a Websockets RFC. Consensus takes time.
As crusty as JS may be, I don't think these are dark times at all. I think the rate of evolution (in JS engines, ES6/7, ..) is so swift it's more worthwhile to stick to the JS platform than to reinvent the web yourself.
Couldn't work out if you're using Groovy as an example of a shoddy language used because there was nothing better (like JS), or a better language that everyone couldn't agree on (like Go/Rust). Groovy was originally based on Beanshell but with closures added, and became mildly popular for scripting on the JVM around 2006 onwards, and its later use by Gradle for 30-line build scripts. A meta-object protocol was added and Grails (a knock-off of Rails) was built to utilize it, though Grails use is on the decline partly thanks to Node.js. Although the backers of Groovy have since added other cruft, it hasn't moved beyond its original use case of scripting the JVM (like Bash for Linux).
You can use and implement COM or XP/COM components in C, C++, JavaScript and (theoretically but not commonly for XP/COM) other languages. XP/COM is not syntactically compatible with COM, and uses a completely different headers, tools, etc, but they're identical in memory layout and behavior and design. Of course beyond identical IUnknowns, XP/COM's interfaces, metadata, and JavaScript interoperability are totally different than ActiveX on IE.
They eventually realized they'd gone too far with it, and went through a "de-COMification" phase around 2002, and it's been a few years since I worked on a xulrunner application, but as far as I know, XP/COM is still pervasive throughout Mozilla/Firefox/xulrunner, including its deep internals and its chrome user interface layer.
COM was a good solution for a particular set of problems at the time, which Mozilla also needed to solve, so XP/COM made sense in that context. But these days, it makes more sense to use JavaScript and JSON directly as the interoperability layer between components and other languages, instead of COM.
JavaScript won the language war, so it gets the privilege of being the "linguistic motherboard" that you can plug other languages, emulators and components into.
I find the implication in the Moore's law section about performance to be a bit unfortunate. Ideas like this only strengthen Wirth's law. We're talking about plain old JavaScript here, after all, not some hypothetical Smalltalk/Erlang hybrid language with mystic productivity benefits or anything like that.
Even now, you're either a Javascript Developer or you're a designer (a designer with HTML/CSS chops but really weak Js skills), the role of the front-end dev has morphed seemingly morphed into this two for some reason.
Tessel created "a compiler that translated the JavaScript source to Lua and executed the translated code on the very compact Lua virtual machine on the microprocessor of the device".
linked: https://tessel.io/blog/98257815497/how-tessel-works-the-basi...
Part of me is appalled that a language as icky as Javascript is taking over the world like this. But I'm happy that any language at all is giving us this level of flexibility and standardization.
I think ECMAScript 6 is definitely a welcome change to the language, ES7 will be undeniably better (even if for Object.observe alone). Now that releases for ECMAScript specifications will be released yearly, we'll see the language evolve and now that we have a nice range of evergreen browsers, developers can take solace in the fact they don't have to support older browsers for much longer (as new features are released, browsers incorporate them).
While Javascript definitely has its warts, what other language can boast of the same market share as Javascript? There is no such thing as a perfect language. Not to mention its low barrier to entry, nothing to deploy, no compiler to configure and how powerful it is in capable hands. I think the success of Javascript was more than being in the right place at the right time, I think its ease of use spurred a booming community. Not to mention the fact you could be confident you can write Javascript and it'll run basically anywhere.
People who feel the need to complain about how bad Javascript is to educate themselves further or most likely have never used it properly. There are definitely bad parts in Javascript, but any decent developer who has a good understanding of Javascript knows what those bad parts are and how to avoid ever encountering them. Any language allows you to write poor code, some just make it easier than others (like PHP).
For me the biggest and most exciting thing to happen to Javascript is React.js. And once it is released if my gut-feeling is correct: React Native is going to drive the Javascript language even further, possibly spurring a JS revolution even more-so than Node.js/IO.js has.
Can't wait till the next big one, because this one isn't doing it for me.
I couldn't be happier for where JS has come.. I use node's tooling daily, and although I do use BabelJS for ES6 features, I find it to be a very good fit (with more functional thinking) for a lot of problems.
1 + "2" = "12" but "1" - 1 = 0
0 == false ( "if window.scrollTop ..." will occasionally break on user scroll )
undefined == null ( why do we need 2 empty sets? )
undefined + "dog" != null + "dog" ( breaks transitive property )
undefined !== null ( but native operators like ? and if uses == and not === )
I'm really glad Javascript is taking over. Mostly because I am a small business / indie dev and using Javascript allows me to off-load a lot of work onto distributed client computers. Which, in turn, allows me to piggy back off of Google, Github, etc., for free hosting and be massively "scalable" to traffic spikes with no cost to me. Js has become massively portable so rapid prototyping and deliver is more possible now than ever.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2] http://stackoverflow.com/questions/359494/does-it-matter-whi...
Seriously, what answer were you expecting other than this?
I'm really curious!
EDIT: Clarified last statement.
> false - 1
> true - 1
Please note that the subtraction operator is not defined for strings in js and the language is loosely typed.
Given those two things, these edge cases are entirely sane... and given the flexibility of the language makes it a very good choice for a lot of tasks. No, it is not a purist mindset when it comes to languages.. but in the context of its' design goals, it makes perfect sense and is easy enough to avoid these scenarios when actually writing code that doesn't interact with user data.
For the record, I've seen C# developers pass around Guid (UUID) as string, even for code that never crosses a wire, and the dbms uses the UUID format. I've seen Java developers do some pretty asinine things too. The language can't always protect you from shooting yourself... in the case of JS for the most part at least a small bug doesn't take the building down with it.
>> "1" - 1 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for -: 'str' and 'int'
- "" (the 1 gets converted to a string, and string-string could have meant remove-if-tail)
- NaN or undefined (bad operations could give bad results)
- "1" (bad operations could be ignored)
- "1-1" (because life is hilarious, and a-b = a+(-b))
- Parse failure (the -1 could get parsed as a constant because there's no string minus int operation, and two adjacent constants is invalid)
- throws (bad operations could act like 'undefined()' does)
Edit: Apart from the terrible behaviors of browsers to just silently ignore all errors.
But honestly, compare each one of these answers to js's official workaround calling the Number() constructor on the primitive string value and attempting to convert to a number since the subtraction operator is only defined for number and then proceeding to complete the operation.
For me, it looks very logical and convincing given that the language is loosely typed and it breaks her heart that it fails any of its loved users :)
1 + "2" (12) does a string concatenation. 1 - "2" (-1) does math.
That said, whilst JS is loosely typed and won't fall over when you do this, I'd just see it as bad form to find code mixing types to this extent. Just because the language will let you do it, doesn't mean you should actually do it!
But all of that's fine compared to PHP's implicit number conversion that ignores trailing characters, presumably so that you can add "3 onions" to "1 kg of bacon" or some such...
Shitty languages will cause devs to have to purchase books entitled "ShittyLanguage: The Non-Shitty Parts", wherein chapter 8 talks about "avoid using the subtraction operator because of ambiguous precedence, transitivity, and coercion rules; instead use jQuery.minus()."
I've seen some pretty horrible code, with any number of bugs in pretty much every language I've ever seen. If you're passing a string into a function that expects a number, you deserve what you get. parseInt(value,10) for user input isn't so hard.. if you want to ensure a numeric value, you can always ~~value ... though that's slightly less obvious to someone new to the language.
JS evaluation expressions are far nicer than most languages I've worked with.. aside from C#'s addition of .? I can't think of much that comes close to as fluid in terms of handling end user input and massaging it into something that works correctly.
Your comments remind me of the XML everywhere mindset that used to be so prevalent in "enterprise" programming... JSON is a much better abstraction for data models, as it is less disconnect from actual code.
Personally, I prefer a "don't cause an error unless you really have to" approach to development... if you can recover from an error condition, log it and do so... if you can't, blow up the world. Java's error handling comes to mind here as particularly cumbersome to deal with... Node's typical callback pattern, and similarly promises/thenables is much easier to work with in practice.
JS has some really hideous parts... just the same, the Browser is an environment where you expect things to do "something" and mostly still work when parts break... the services that back browsers should likely do the same. JS is a good fit for this use case.
return a+b-b
Now tell me, what is f("1",2)? Is this really what you would expect? Treating strings like strings sometimes and integers other times messes up functions, creating bugs that are extremely hard to track. Usually you can get back what you started with if you subtract after you add, but JavaScript ruins that unless you first check that the input are numbers. If it always tried to coerce the string into an integer or vice versa then it would be fine.
The problem with people coming from more classical programming languages to learn js is that some have this condescending attitude toward the language from the get go and expect that by the virtue of having C/Java experience under the belt, that everything should look similar in js and when they encounter something like "automatic type casting" they freak out and start dissing the language but once they seriously put the effort to understand it, their frustration and bad experience starts to give away to a more positive experience and consequently more positive sentiment toward the language.
So for me it's just a question of attitude and story of prejudice and perceived supremacy of one's own language background at play here.
JavaScript forces you to work more to get predictable type conversions by having a lot of random conversions. While each of those conversions might make sense the combination of them usually doesn't. Why can I use other maths operators to coerce the string into a number but not '+'? Because '+' is a special case since it tries to coerce to a string before it tries to coerce to an integer, it isn't hard to get that. But it makes the other conversions dangerous since when you want to use '*', '-' or '/' you usually want to use '+' as well but as it is the other works but not '+'. What would make sense is to either remove the special case of '+' or you add special cases for the other operators so that they act similarly as '+' with strings.
So it is definitely not as easy as you make it seem.
Maybe you meant Blink, WebKit uses JavaScriptCore