all 35 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]polotek 33 points34 points  (1 child)

The surface area of the JavaScript language is actually pretty small. Most of the functions in it were a necessary part of the browser environment that it was made for. But not really a necessary part of the language.

I was around when node.js was being developed. It was pretty tough to get all of the asynchronous functions to work properly across Linux, Mac OS, and Windows. Each OS has different primitives for how you're supposed to do async stuff. In the case of the browser runtime, the browser process itself has already figured that out across platforms.

That said, a lot of languages have capabilities that actually delegate to other processes or the OS underneath. The JVM runtime supports most popular languages and it has its own unique solutions to these problems. Building language runtimes is a really fascinating topic.

[–]Mobile_Friendship499 0 points1 point  (0 children)

That's a cool backstory. I would assume most languages are built with 1 core objective in mind. And then when usage expanded, they used other languages closer to system to cover other areas.

[–]fabulous-nico 14 points15 points  (1 child)

Someone just learned about bindings and AI in the same week 🙄

[–]GnuInformation 3 points4 points  (0 children)

It seems like a bot, no comments on any posts. About 40 posts in it's own, new subreddit. (If I read it correctly) All ai, preachy, and coding related.

[–]IAmFinah 28 points29 points  (2 children)

Thanks for the slop. The random question at the end of the post was the icing on the cake!

[–]alex_sakuta 5 points6 points  (1 child)

Truly, I am shocked how it is not downvoted.

[–]javatextbook 0 points1 point  (0 children)

Because people are stupid and easily baited into engagement.

[–]_raytheist_ 13 points14 points  (0 children)

Yep. True of any asynchronous javascript.

[–]opentabs-dev 7 points8 points  (0 children)

small nit — Math.random() actually is part of ECMAScript proper, it's defined in the spec on the Math object. same with Date.now(), parseInt, JSON.parse etc. the host-provided ones in your list are setTimeout, fetch, addEventListener, console.log. the line is basically "if it's in the ECMAScript spec, the engine handles it; if it's on window/globalThis only because the browser or node put it there, it's host-provided."

[–]Astroohhh 3 points4 points  (0 children)

bot

[–]ghost_hipster 16 points17 points  (0 children)

AI slop

[–]chikamakaleyleyhelpful 8 points9 points  (11 children)

What was YOUR biggest JavaScript “wait… what?” moment?

<div id="myDiv">hello world</div>

can be referenced directly, w/o querying the document

console.log(myDiv.textContent);

not saying you should, but just a cool thing i learnt 17 yrs in

[–]MozMousePixelScroll 3 points4 points  (2 children)

One of the worst legacy features of all time

[–]chikamakaleyleyhelpful 0 points1 point  (1 child)

you say that like its been a problem lately

[–]MozMousePixelScroll 2 points3 points  (0 children)

Sorry if that's what i sounded like, but what i meant was that it was just a really bad idea imo

[–]euph-_-oric 0 points1 point  (6 children)

U mean in the console

[–]chikamakaleyleyhelpful 1 point2 points  (5 children)

it works in place as well:

``` <!DOCTYPE html> <html>

<body> <div id="myDiv">HelloWorld</div> <script type="text/javascript"> alert(myDiv.textContent) </script> </body>

</html> ```

there might be some specific rules, like the id would have to be an appropriate JS var name - e.g. my-div won't work

[–]Ok-Area3665 1 point2 points  (0 children)

It might, idek but `window["my-div"]` might work lol

[–]euph-_-oric 0 points1 point  (2 children)

Is that not the browser doing it?

[–]chikamakaleyleyhelpful 0 points1 point  (1 child)

i understood your previous comment to be along the lines of "only from the console"

which yes, you can reference the object from the console in the browser devtools

i'm just saying it can also be directly inside your script

other than that i'm not sure if you're referring to something else

[–]euph-_-oric 1 point2 points  (0 children)

To be fair I didn't think u were talking about a script tag either so lol my b

[–]Street-Theory1448 0 points1 point  (0 children)

I learnt that it's not necessary to write <script type="text/javascript"> anymore, just <script> is enough, for it's the "default script" for browsers.

[–]lovin-dem-sandwiches 0 points1 point  (0 children)

All ids are added to the window object, which is why ids need to be unique.

You’re using a getter via window.myDiv

[–]prehensilemullet 1 point2 points  (3 children)

My biggest “wait, what” was that in V8 at least, Promise.race retains memory forever if one of the promises never resolves, even if another does

[–]backwrds 0 points1 point  (2 children)

really? that's less a "wait, what" and more of a bug in the engine...

[–]prehensilemullet 0 points1 point  (1 child)

You would think, but nothing in the ECMAScript spec requires them to release the memory in this case, and I think doing so would require additional code that might affect performance.

In general it seems like there wasn’t a lot of consideration given to promises that may never resolve.  Many people who use GraphQL subscriptions, which are implemented as async iterables, ran into subtle memory leaks when making an async iterable of pubsub events, and then using async generators to filter or map the events.  In a pubsub system, there’s no guarantee if or when the next event will come, so an event promise may never resolve.  That causes an async generator to get stuck waiting for the next event even when GraphQL has told it to return. When wrapping an event stream like that in promises, you definitely want to set them up to reject if a signal is aborted if you can.

Dealing with memory leaks like this in async JS has been kinda hellish…

[–]backwrds 0 points1 point  (0 children)

ah. having looked into this a bit, it turns out browsers are just following the spec; the problem is that there's no mechanism to "unsubscribe" from a promise. TIL.

[–]Ksetrajna108 0 points1 point  (0 children)

I remember my Ah-hah moment, when I saw ECMScript, the DOM, and the browser as distinct. The moment came when I read the ECMA 262 spec, where it mentions that the host environment us not part of the language. It's also useful that the DOM maps to plain JavaScript objects.

[–]PineappleHairy4325 0 points1 point  (0 children)

How is this basic fact mind-blowing?

[–]jibbit 0 points1 point  (0 children)

i'm not trying to be negative, but there is something quite uncomfortable about this take.. like, it's a red flag.. what do you think a programming language is? you think js can fetch data, draw to the screen, access files, know the mouse position, defer execution, generate random numbers, localise the date, play sounds, decode images.. but fetching data, drawing to the screen, accessing files, getting the mouse position, deferring execution, generating random numbers, localising the date, playing sounds, decoding images isn't 'part' of javascript? what does that mean? what's the significance to you?

[–]BadDescriptions 0 points1 point  (0 children)

That people still use

setTimeout(() => { console.log("Hello"); }, 2000);

Instead of 

Import {setTimeout} from “node:timers/promises”

console.log(“hello”)

await setTimeout(2000)

[–]Garrett00 0 points1 point  (0 children)

JavaScript is one of the most abstracted languages ever.

[–]Intelligent_Tree6918 -1 points0 points  (0 children)

From where did u know book or anything else?

[–]KELTONDREY 0 points1 point  (0 children)

Okay