

It is resource hungry. I’ll give you that. But it’s neither slow nor messy to look at. Have you ever used NetBeans or Eclipse?


It is resource hungry. I’ll give you that. But it’s neither slow nor messy to look at. Have you ever used NetBeans or Eclipse?


I’m sorry I didn’t think it was [1,2].


Here’s my thought process: plus is for numbers and strings, so it’s gonna convert the arrays to either numbers or strings. If it converts them to 0, the answer is 0, if it converts them to 1, the answer is 2, if it converts them to strings, the answer is “12”.
You know what I didn’t say? [1,2]. Because plus is not for array concatenation. The question is meant to make you think you’ll get [1,2], because why else would you use plus on arrays?
In a language that uses plus for concatenation, you’ll see that kind of code all over, and know what you’ll get. But you never see that in JavaScript, because that’s not how we concatenate arrays.


Ok, except I did predict it. It turns them both into strings and gives you “12”. I checked it. But I didn’t mean predictable as in, you inherently know what it’s going to do, I meant predictable as in, it will follow the same basic rules in each circumstance.
So, should web pages be prone to crashing if everything isn’t perfect? I don’t know if you remember XHTML, but that was basically what happened with that. You have a “div” within a “p”? Page crashed. You have an unclosed “span”? Page crashed. XHTML was abandoned because is constantly broke the web.
Web technologies are supposed to be resilient, so throwing TypeError is the last resort for something that absolutely cannot work, like trying to add to a Symbol. Since nothing from the user is ever a Symbol (there’s no input that can give it, and it can’t be stored in JSON), it’s acceptable to throw a TypeError there.
JavaScript is meant to be fast and resilient. Its type conversions make sense when you consider those goals.


I mean how can you define a sensible way to subtract Infinity from an array, or add an object to a string? The way JavaScript defines it is predictable, easy to compute, and handles bad code gracefully, which is a good tradeoff between doing something like matrix arithmetic on a CPU and just straight up crashing. If you’re doing silly things like that, you should know how JavaScript coerces types, but I don’t do silly things like that, so I don’t really care how JavaScript would handle it. Every language will do silly things if you force it to. That doesn’t make it a bad language.
Do you feel the same about C because C lets you take pointers of pointers of pointers until you’re addressing random memory in an unpredictable way? No, because it’s silly to do that.


Yes, if you do silly things with JS, you generally get silly results instead of TypeErrors. I wouldn’t say that makes the language bad. It makes the language resilient to bad programming, which you’d generally want in the case of web pages.


No.
By that same logic, memory safety issues in C/C++ don’t make them bad programming languages.
If you’re worried about it, like you’re accepting input from the user, sanitize it.
if (typeof userProvidedData !== "string") {
throw new Error("Only works on strings.");
}
Better yet, put that in a function called assertString.


Your VSCodium reserves ~8 GB of ram? You might want to check the extensions you’re using. I’ve got mine running with tons of open files and it’s using ~2 GB.

Also, you should definitely give Immich a try. It’s an awesome piece of software.


JS has been made less shitty. I’ll give you that old JS was pretty shitty. Like v5 and lower were a huge pain. But a lot of that was because of the lack of modern language features that other languages had at the time. ES6 introduces some huge improvements that made JavaScript much less frustrating. Personally, at this point, I have very few pain points with the language.
I don’t think being included in browsers is the only reason JS became so popular, but it’s definitely the biggest reason. That doesn’t make it a bad language.
Backwards incompatible changes have been introduced in JS a number of times. They are opt in at the script level and enforced in newer language contexts.


I would assume [1] + [2] would give you either 0 or 2, but maybe "12". But why you ever write that? I’ve never bothered to memorize what happens there because I would never write that. The plus operator is not for arrays. It’s for numbers and strings. If you’re trying to concatenate arrays, there’s a function for that. Would you do that in Java or C? People trying to make JavaScript do silly things just because it refuses to crash when you do then calling the language bad for it is just silly to me.


Have you ever looked at the original JS implementation? It looks nothing like what JS is today. Saying the bones were spat out in a couple weeks is like saying Linux was developed in a few months.
TS transpiles to JS, and any JS is valid TS. Take any TS, remove the types (and some syntactic sugar) and you have JS. I feel like if you like TS but not JS, you just don’t like loosely typed languages. That’s just a preference. It doesn’t make a language bad.


Yeah, I’ve seen a lot of those videos where they do things like {} + [], but why would anyone care what JS does in that case? Unless you’re a shit-ass programmer, you’re never going to be running code like that.
The idea behind that kind of type conversion was that JS was originally designed to be extremely lenient. If it ever crashed, the web page would freeze, so it lets you do things other languages just crash from, like divide by zero.


It’s just strict typing on top of plain JS. I like strict typing. Some people like loose typing.


Considering TypeScript is a superset of JavaScript, you certainly can. But, that generally means you’re using TypeScript poorly.


I’ve never really found the type conversions that bizarre, unless you’re doing something weird like casting an array to a string or number. I don’t really use strange type casts, since I use TypeScript and avoid using the “==“ operator. What other things make it not good?


I think you’re thinking of Electron apps, but that’s not really a criticism of JavaScript, that’s a criticism of Electron. There are plenty of JS platforms that don’t require a browser/DOM. React Native is the biggest example. Also, GJS if you want native Linux apps.


What makes it not good?


It’s written for Node and Svelte. But sure, just like nearly all other software, they use external libraries.


I didn’t say that. You can make great software in Brainfuck, but I don’t think anyone has ever said it is good because of that.
People do make good software in JavaScript. Knowing JavaScript is an exceptionally useful skill, and JavaScript is pretty easy to become decent at. The learning curve for JavaScript is relatively low. As such, there are tons of JS devs, many of which want to make cool things. JavaScript is undeniably an approachable language. Whether you personally think it’s a good language doesn’t have any bearing on that, but that means tons of people are going to use it to make cool software. To me, its approachability is one of the many things that make it good.
Then don’t use Ubuntu yourself. You can’t control what your friend does.
Most you can do is tell them why you don’t use it if they’re willing to listen, but if they don’t mind the reasons you give, let them be.