Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

V8 Release v9.4

v8.dev

Post reply on HN
Print view View original

11–20 of 33 posts

Re: V8 Release v9.4

#11

Post by vaughan »

nicoburns wrote: post #7
geewee wrote: post #3

I honestly think the newer ECMAScript features with static blocks, private fields are a little strange. I get that some people really want JavaScript to be object-oriented - but I wonder if we wouldn't be better off embracing and building on its functional side.

Yeah, I find them utterly bizarre. I find it hard to believe that people using private implementation details is a real problem that people have. Underscore prefixing is a well-established convention within the JavaScript ecosystem, and with typescript it's easy to hide fields from the static types. I'm usually up for new language additions, but I can't see the benefit to this added complexity at all.

It's driven by library developers wanting to prevent access to internals. I was annoyed by it initially because I love poking around in internals and it makes it easy to add missing functionality or fix bugs, but I can kind of understand from popular library maintainers.

If Bar depends on a private internal of Baz, and Foo depends on Bar, then if Baz publishes a patch version that changes an internal to fix a bug, Bar breaks, and so does Foo.

Re: V8 Release v9.4

#12

Post by ectopod »

vaughan wrote: post #11
nicoburns wrote: post #7

Earlier quoted context omitted.

Yeah, I find them utterly bizarre. I find it hard to believe that people using private implementation details is a real problem that people have. Underscore prefixing is a well-established convention within the JavaScript ecosystem, and with typescript it's easy to hide fields from the static types. I'm usually up for new language additions, but I can't see the benefit to this added complexity at all.

It's driven by library developers wanting to prevent access to internals. I was annoyed by it initially because I love poking around in internals and it makes it easy to add missing functionality or fix bugs, but I can kind of understand from popular library maintainers. If Bar depends on a private internal of Baz, and Foo depends on Bar, then if Baz publishes a patch version that changes an internal to fix a bug, Ba…

Can't you already hide your implementation details using a closure?

Re: V8 Release v9.4

#13

Post by antihero »

geewee wrote: post #3

I honestly think the newer ECMAScript features with static blocks, private fields are a little strange. I get that some people really want JavaScript to be object-oriented - but I wonder if we wouldn't be better off embracing and building on its functional side.

I wish they could add pattern matching statements.

Re: V8 Release v9.4

#14

Post by kccqzy »

ectopod wrote: post #12
vaughan wrote: post #11

Earlier quoted context omitted.

It's driven by library developers wanting to prevent access to internals. I was annoyed by it initially because I love poking around in internals and it makes it easy to add missing functionality or fix bugs, but I can kind of understand from popular library maintainers. If Bar depends on a private internal of Baz, and Foo depends on Bar, then if Baz publishes a patch version that changes an internal to fix a bug, Ba…

Can't you already hide your implementation details using a closure?

Yes you can. But few libraries actually do that.

Re: V8 Release v9.4

#15

Post by Waterluvian »

geewee wrote: post #3

I honestly think the newer ECMAScript features with static blocks, private fields are a little strange. I get that some people really want JavaScript to be object-oriented - but I wonder if we wouldn't be better off embracing and building on its functional side.

I’m perfectly happy for a language to have feature coverage for others to do what they like.

I’ve found incredible success using JS (TS) as a functional language. Oh my god I love it. It’s so easy to test. So easy to reason about. So predictable.

State is my enemy. Optimization can be hidden away in the form of memoization rather than partially mutating object state.

Does this work for all use cases? Nope. Classes are fine. They sure beat the five or so fake ways to do classes before ES6.

I’ll settle down now.

Re: V8 Release v9.4

#16

Post by Waterluvian »

xpressvideoz wrote: post #9
geewee wrote: post #3

I honestly think the newer ECMAScript features with static blocks, private fields are a little strange. I get that some people really want JavaScript to be object-oriented - but I wonder if we wouldn't be better off embracing and building on its functional side.

Some JavaScript people have been hostile to functional concepts since the beginning. See the missed opportunity to make Promise a monad.[1] [1] https://github.com/promises-aplus/promises-spec/issues/94

I’m curious if someone can sell me, practically, in relatively few words, what that would gain us compared to Promises today.

That link wasn’t sufficient to teach me. I’m a bit dense. :(

Re: V8 Release v9.4

#17

Post by jancsika »

brundolf wrote: post #10
geewee wrote: post #3

I honestly think the newer ECMAScript features with static blocks, private fields are a little strange. I get that some people really want JavaScript to be object-oriented - but I wonder if we wouldn't be better off embracing and building on its functional side.

IMO classes are almost pointless without private fields; hiding state (in the handful of cases where that's really actually what you want) is one of their main legitimate uses But using static members in a language with module-level constants, functions, etc. just seems incredibly silly to me. And then expanding on that feature with exotic new syntaxes like this feels regressive.

Yes!

In Javascript I write a closure that returns an object full of methods.

If I want private state I put the variables in that closure.

Nothing bad has happened to me yet. :)

Re: V8 Release v9.4

#18

Post by nicoburns »

vaughan wrote: post #11
nicoburns wrote: post #7

Earlier quoted context omitted.

Yeah, I find them utterly bizarre. I find it hard to believe that people using private implementation details is a real problem that people have. Underscore prefixing is a well-established convention within the JavaScript ecosystem, and with typescript it's easy to hide fields from the static types. I'm usually up for new language additions, but I can't see the benefit to this added complexity at all.

It's driven by library developers wanting to prevent access to internals. I was annoyed by it initially because I love poking around in internals and it makes it easy to add missing functionality or fix bugs, but I can kind of understand from popular library maintainers. If Bar depends on a private internal of Baz, and Foo depends on Bar, then if Baz publishes a patch version that changes an internal to fix a bug, Ba…

I think React have the right approach. If something isn't part of the committed to public API, then it's named `__unstable_foo`. Consumers of the library are free to use them, but they can and will change at the whim of the maintainers regardless of any stability guarantees that the library usually provides.

This allows advanced consumers to tinker where they need to and are prepared to take on the maintenance while leaving potential complainers no leg to stand on if the API changes.

Re: V8 Release v9.4

#19

Post by brundolf »

jancsika wrote: post #17
brundolf wrote: post #10

Earlier quoted context omitted.

IMO classes are almost pointless without private fields; hiding state (in the handful of cases where that's really actually what you want) is one of their main legitimate uses But using static members in a language with module-level constants, functions, etc. just seems incredibly silly to me. And then expanding on that feature with exotic new syntaxes like this feels regressive.

Yes! In Javascript I write a closure that returns an object full of methods. If I want private state I put the variables in that closure. Nothing bad has happened to me yet. :)

I would argue that that method (no pun intended) is less clear about intent and harder to read

There are lots of things like this where the OOP version and the FP version are technically interchangeable in terms of capability, but not in terms of ergonomics or readability. A beautiful thing about working in a multi-paradigm language like JS is that you can reach across the aisle for the best tool for any given job. You can use classes to hide state, plain functions instead of statics, lambdas instead of anonymous classes, etc.

Re: V8 Release v9.4

#20

Post by LouisSayers »

jancsika wrote: post #17
brundolf wrote: post #10

Earlier quoted context omitted.

IMO classes are almost pointless without private fields; hiding state (in the handful of cases where that's really actually what you want) is one of their main legitimate uses But using static members in a language with module-level constants, functions, etc. just seems incredibly silly to me. And then expanding on that feature with exotic new syntaxes like this feels regressive.

Yes! In Javascript I write a closure that returns an object full of methods. If I want private state I put the variables in that closure. Nothing bad has happened to me yet. :)

Ah yes, the good parts :)

I've found understanding exactly how JS works to become more confusing with class structures.

It feels like you need a PHD in JS to have a good grip on how it all works under the covers.

Using Crockfords closure strategy for me was quite straightforward and simple, and I've enjoyed doing:

const MyClass = {}; MyClass.new = () => {}; const instance = MyClass.new();

Which leaves all the "this." ugliness behind and provides a ruby-like instantiation.

Post reply on HN