Live data from Hacker News

Proposal: JavaScript Structs

github.com

341–350 of 371 posts

Re: Proposal: JavaScript Structs

#341
post #308

Earlier quoted context omitted.

I like JS's flexibility too, but I have to point out that your object-oriented JS code is compiled into C++ classes by the v8 optimizer! (Unless you change their structure, in which case it gives up (deoptimization).)

Does it compile something like this into a c++ class? makeThing(options, usethistoo) { let foo = options.foo; let thistoo = usethistoo; return { functions... } }

I'm not sure if "C++ class" is the right term, but it will certainly compile into a class behind the scenes [1]

You can use d8 to check what the class structure ends up looking like [2]

---

[1]: https://v8.dev/docs/hidden-classes

[2]: https://v8.dev/docs/d8

Re: Proposal: JavaScript Structs

#342
post #311

Earlier quoted context omitted.

Because I think in objects (non-strictly related groups of data and methods) and it’s natural to how my business processes work. Light OOP creates neither translation nor maintenance layers to it. See https://news.ycombinator.com/item?id=41808034 I'm guessing JS wasn't your first language Good intuition. My first language was basic, 8080 asm, x86 asm, pascal, C, perl, python, haskell (most useless), lua, objc. Js/ts…

:) I started with 6800 machine language. Then c, smalltalk, scheme and etc. Rather than spend a lot of time and botch a comparison between classes and factory functions I'll link you to an article. He went further, introducing something he calls stamps, but I found them to be awkward the only time I tried to use them. https://medium.com/javascript-scene/javascript-factory-funct...

Thanks, this added to my standard low-level experiments in a new language. The most interesting (or should I say well thought-through and at the same time tricky) part of js is how prototypes and properties work. Rarely a language has a similar complexity at that level, but I started to respect it the second I’ve got an overview, cause it addresses well the pain points that simpler designs usually have.

That said, for me it’s hard to buy into his arguments, in a sense that it doesn’t matter that much, if at all. instanceof doesn’t work for different realms and is nuanced for direct prototyping and Object.create(), but I never use or care about these in my code, by design. There’s no way that such value could appear in a false-negative instanceof comparison, so. A similar thing happens in COM/OLE integrated runtimes, where you have to be careful with what quacks like a date or a string but is neither due to a wrapper. But that’s expected.

I believe the real issue here is that iframes/etc usually get served as “some values aren’t, so use X, be careful” rather than “guys it’s an effing wrapper to an effing different runtime, which we found to be an overall anti-pattern many years ago”. Browsers and webguys normalized it, well, they normalized many crazy stuff. Not my problem. There’s no need to learn to balance on two chairs when it’s not what you do when sober. I still use Array.isArray(), but only because every linter out there annoys you to hell into it.

Tldr: classes are neat you can pry them from my cold dead hands.

The only thing to care about with classes is to not fall into the inheritance trap, and not for the reasons of instanceof. Inheritance is a tree of ladders attached with a duct tape, you have to know what you’re trying to do to your design before thinking about it. Most sane use of inheritance is one-off from a library to a user (two separate developing agents agree on an implied behavior, “I implemented it for you to randomly extend and pass back” mode), or for helping type inference. Otherwise, a way to go is to eject a common behavior into a separate class or a couple of functions (aka composition).

Re: Proposal: JavaScript Structs

#343

Earlier quoted context omitted.

I wonder why it seems natural to you? I'm guessing JS wasn't your first language and you didn't learn the power of composition instead of classes.

Hello JS was my first language and I use classes because sometimes it seems like the obvious way to model things. Looking through the source of Replicache, here are some classes we use: - KVStore - DAGStore - Transaction I mean ... I can of course model these w/o classes, but encapsulating the state and methods together feels right to me. Especially when there is private state that only the methods should manipulate.…

Honestly, all this “emulated with prototypes” meme is misleading. Prototypes are an implementation of what they’ve called “binding” before (some may recognize “early” and “late” in this context). That’s how classes work and what classes are. The fact that some gears got exposed to a user [to stick their fingers into] doesn’t change much.

So no, javascript didn’t really “add classes”. It just had a very annoying lower-level syntax for them from the beginning and fixed it after a while. It wouldn’t survive the pressure if it had no classes at all cause this idea is fundamental to programming and to how we think: you-do.

One may pretend to not have classes through closures, but technically that’s just classes again, cause you have a bunch of functions with a shared upvalue block. You just hold it the other way round lexically, by a method instead of a context.

I believe this common idea of alienating classes stems from the general OOP stigma since the times of “design patterns”.

Re: Proposal: JavaScript Structs

#344
post #55

Earlier quoted context omitted.

There's a lot of that, certainly, but there are legitimate reason to use JS/TS. Frontend is an obvious one but also using services like CF Workers or Deno Deploy which are optimized for V8. You're going to get better uptime and lower latency than anything else at that cost.

Serious question, when would you want to use synchronization primitives in the frontend? I've seen the discussion revolve around service worker / web worker usage, but I think sharing ressources between a worker and the main thread has been discussed in the past and has ultimately been abandoned for security reasons.

what do you mean with "synchronization primitives"?

do you mean like reactive data?

Re: Proposal: JavaScript Structs

#345
post #342

Earlier quoted context omitted.

:) I started with 6800 machine language. Then c, smalltalk, scheme and etc. Rather than spend a lot of time and botch a comparison between classes and factory functions I'll link you to an article. He went further, introducing something he calls stamps, but I found them to be awkward the only time I tried to use them. https://medium.com/javascript-scene/javascript-factory-funct...

Thanks, this added to my standard low-level experiments in a new language. The most interesting (or should I say well thought-through and at the same time tricky) part of js is how prototypes and properties work. Rarely a language has a similar complexity at that level, but I started to respect it the second I’ve got an overview, cause it addresses well the pain points that simpler designs usually have. That said, fo…

Fair points. I do use classes exposed by libraries. I don't like it but it beats the alternative.

I really like the flexibility of factory functions, that is the main point of the article imo.

COM/OLE ... that takes me back to the early 90s, a place I hoped to never visit again!

:)

Re: Proposal: JavaScript Structs

#346
post #306

A stricter, faster subset of JS would be very welcome, which seems to be what the unshared struct part of this proposal provides. By the way, doesn't V8's optimizer already do something like this internally? I read one of their tech blogs back in the day that explained how they analyze the structure of objects and whenever possible, compile it to the equivalent of a C++ class. I guess doing it explicitly makes the op…

Not JS, but quite the same niche is where AssemblyScript sits: https://www.assemblyscript.org/

Re: Proposal: JavaScript Structs

#347
post #25

Earlier quoted context omitted.

Java went through this too, although there, a lot of it is part of the ecosystem. See https://chrisdone.com/posts/tamagotchi-tooling/

The java tooling is the number one thing I hate about using the language. It's all just bad. Then. You get forced into using intelij because it seems to smooth over a lot of the toolings problems with "magic". It's horrible.

Everything you said applies to Kotlin as well. Outside of IntelliJ, it is horrible to use. (Ditto Swift outside of Xcode.)

Re: Proposal: JavaScript Structs

#348

Earlier quoted context omitted.

Every programming language attempts to expand until it becomes C++. Those languages which cannot so expand are replaced by ones which can.

Go will resist this as long as possible.

Lua too. 30 years and counting!

Re: Proposal: JavaScript Structs

#349
post #229

Earlier quoted context omitted.

At least in C# you can ignore most of it and the complexity doesn't really come from numerous foot guns. You can still write Java 1.6/.NET 2 style C# code just fine, it's all there. The rest of the features can be fully ignored and they won't hurt you. But then again the newer features they do make writing code a lot nicer, giving more compile time analysis warnings etc hopefully resulting in slightly better code. An…

You can still write ES5 and it will work in the latest JS runtimes, so I'm not sure how this is different. Further, indeed the newer JS features do in fact give you better compile time analysis, warnings, etc, and result in slightly better code.

You can even write ES3 and it should work in all web browsers.

Re: Proposal: JavaScript Structs

#350

I don't understand the need for the ever-growing list of "enhancements" to JS. Take Class for example. Class is entirely unnecessary and, essentially, tries to turn JS into a class-oriented language from its core which is object-oriented. I never create classes. I always create factory functions which, when appropriate, can accept other objects for composition. And I don't use prototypes, because they are unnecessary…

Classes generally point you towards writing more performant code. Factory functions allow you to achieve the same performance, you just have to be a bit more careful not to cause a depot :) For example, 1. field declarations [1] make sure that the fields are always initialized in the same order. That way most of your functions end up monomorphic, instead of being polymorphic [2] 2. Method declarations are also (almos…

The difference in performance is negligible for all but the most demanding applications. In which case I would still use factory functions, but just be more careful.
Post reply on HN