- It runs in the browser
- Web developers know it already so we might as well
- Job security
- its not COBOL
It’s* not
If you are understood buy you’re audience, you have spoken correctly. Correcting someone’s grammer is pointless
😂😂😂👍
- Ubiquitous; insane amount of libraries and probably some of the best documentation of any language
- JS lambda function syntax is nice
- You can call it “Java” to enrage other programmers
- You can compare numbers against strings without wasting time converting them
Array(16).join(“wat” - 1) + " Batman!";
If you’re living in 2002 and not using the strict equality operator, that’s on you
But what if I don’t want strict comparison? What if my frontend contains a text field for a numeric input and I wanna manually check against each possible valid input value
if (input_val == 1) {...} else if (input_val == 2) {...} else if...without having to convert it first or check that it’s actually a number or fix my frontend?(I’m sure there are valid use cases for non-strict comparison, I just can’t think of one right now)
You can make minecraft mods
that’s java
- it’s easy to make fun of
- it makes every other programming language look better in comparison
It leads to typescript
You get surprises from npm
I spent way too long today figuring out why my app was doing something that it’s NOT supposed to do on weekends.
I read Luxon’s docs (pretty cool lib tbh) again and again, and tried everything I could think of to get isWeekend to return a sane result.
Turns out I was pulling a somewhat older version of Luxon, where isWeekend didn’t exist. In any sane language, I expect I’d get a huge warning about a property that doesn’t exist, but alas…
Typescript helps me keep my sanity, but juuuuust barely.
If isWeekend doesn’t exist, then the weekend doesn’t exist, so it’s naturally false.
That’s why JavaScript gets pushed so hard - it’s part of the capitalist agenda to keep us working 7 days a week
Weren’t you getting runtime errors for the function not being found?
No, they were probably getting false every time
You get suprises from npm
- It’s not PHP.
- I don’t know. I didn’t think I’d get this far.
PHP has gotten really good over the past few versions, actually. Lots of really great stuff has been added, it feels like it resembles rust more every release lol
- It’s not PHP
- It’s already implemented in browsers
hmm, let’s see.
It’s not java.
It’s also not a scripting language.
also to the repeat grammar nazi in the comments here, hi, “its”
It’s not a scripting language?
A lot of people are familiar with it and…um…hackers like it being in use?
You’ll find an npm package to help you count up to 2.
(I recently learned - maybe here - that the is-even package has over 170k weekly downloads)
What’s even wilder is if you look at the code of that package, all it does is include the is-odd package and then return !is-odd. And the is-odd package isn’t much better, it does some basic checks on the input and then returns n % 2 === 1.
I thought I was missing something. JS is one of my main languages and I always just write the is-odd function myself since it’s like 10 characters. It boggles the mind that is-even has 176k weekly downloads
To be fair having a name can make things easier to read. I get that
i % 2 == 0is a common pattern and most programmers will quickly recognize what is happening. ButisEven(i)is just that much easier to grok and leaves that brainpower to work on something else.But I would never import a package for it. I would just create a local helper for something this trivial.
Exactly what I would do if I had to reuse it, especially now since I know that adding a package would actually add 2. It all just seems so…inefficient
Even if the code isn’t reused adding names to sub-expressions can be very valuable. Often times I introduce new functions or variables even if they are only used once so that I can give them a descriptive name which helps the reader more quickly understand what is happening.
Yeah, I do that with pretty much every separate operation in c# since our solutions are pretty big. Most of my JS scripts are just done in ServiceNow which are separated and named appropriately.
Is-even continues to be the best joke in the industry
This must be a “hold my beer” kind of joke and someone wanting to see how far they can take it.
!!isAdvantage
- It has the simplest multi-threaded implementation: no threads!
- You can goof off while your build system takes 20 minutes to rebuild a non-compiled language
node_modules size of a Linux distro
- It runs in browsers
- If you hate your co-workers, then they will also feel your pain.
The part that always gets me is when people choose Js for the backend. Like I get that it’s the default thing that works on the frontend, so there’s some rationale why you might not want to transpile to it from another language. On the backend though, there are so many far better option, why would you willingly go with Js, especially given that you’re now forced to do all your IO async.
You really should be doing your IO async. Do you specifically mean callback hell?
No I meant having to do async as opposed to having threads like you would in Java for example. In vast majority of cases a thread pool will work just fine, and it makes your code far simpler. Typically, Java web servers will have a single thread that receives the request and then dispatches it to the pool of workers. The JVM is then responsible for doing the scheduling between the threads and ensuring each one gets to do work. You can do async too, but I’ve found threads scale to huge loads in practice.
Green threads are functionally the same, especially in languages that can preempt.
Sure, but the scheduler figures out the scheduling automatically so you don’t have to worry about stuff like blocking.
Server side rendering looks like it could be useful. I imagine SSR could be used for graceful degradation, so what would normally be a single page application could work without Javascript. Though, I’ve never tried SSR, and nobody seems to care about graceful degradation anymore.
Most pages tend be just documents and fairly simple forms. Making SPAs and then having to worry about SSR is just making a Rube Goldberg machine in most cases. I think something like HTMX is a much better approach in most cases. You keep all your business logic server side, send regular HTML to the client, and you just have a little bit of Js on the frontend that knows how to patch in chunks of HTML in the DOM as needed. Unless you have a highly interactive frontend, this is a much better approach than making a frontend with something like React and adding all the complexity that goes with it.
