Live data from Hacker News

V8 Release v9.4

v8.dev

31–33 of 33 posts

Re: V8 Release v9.4

#31
post #26

Earlier quoted context omitted.

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. :(

Basically, the current promises take a shortcut. If your promise returns a promise, the two promises are automagically combined into one promise. foo .then(() => returnsAnotherPromise()) .then(() => { /*only receives the nested promise*/}) The correct solution would not automatically flatmap foo .then(() => returnsAnotherPromise()) .then(innerPromise => { innerPromise.then(() = {}) //now we have access to the nested…

I’m surprised to discover that promise flattening. Never noticed it before. Thanks!

Re: V8 Release v9.4

#32
post #29

Earlier quoted context omitted.

> There's no need to be rude. I didn't intend to be rude (I'm sorry for any offense it might have caused). It was a general complaint not aimed at you or anyone else in particular. > A newcomer who encounters the closure method, on the other hand, has to mentally reverse-engineer how it works and what its goal is if they haven't seen that pattern before, because closures are much more general than classes and because…

> If you want to use any bundler or build tool created in the past 15 years, it's going to use closures for anything but the most recent projects. CommonJS which is still ubiquitous in NodeJS is literally closures. When it was created, it literally wrapped your file in a function that passed in some variables like global or import then called eval on the module it had now created. These are all implementation details…

Let's look at the most popular JS books over the past decade.

* JS modules are in the seminal "Javascript: The Good Parts".

* "Eloquent Javascript" has an entire chapter called "modules" and that has existed across all three versions

* "Javascript: The Definitive Guide" also has a section on modules.

* Javascript.info contains an entire section about modules.

* "Exploring JS" contains a section on the module pattern.

* "You Don't Know JS" has even more about it.

I don't see how someone could know JS as a senior or even mid-level developer without having read at least one of these sources let alone the years-long barrage of blog articles.

I can say with 100% certainty that you cannot write properly using any modern framework without understanding closures (of which modules are one of the easiest patterns).

That's not "being purist". That's not requiring everyone to read the latest ECMAScript spec. That's a simple acknowledgement of the day-to-day reality of the job in a typical company.

Re: V8 Release v9.4

#33
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 get that some people really want JavaScript to be object-oriented

JavaScript has always been OO, just originally exclusively prototypical OO rather than class-based OO.

> but I wonder if we wouldn't be better off embracing and building on its functional side.

But modern JS has tended to reinforce both the functional and OO sides of JS. Reinforcing one doesn't prevent the other.

Post reply on HN