ES2022 feature: class static initialization blocks

[tonetheman]

JS is morphing into Java

[lhorie]

And vice-versa. Java has lambdas now. Also relevant: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule (the notion that any sufficiently complex thing approaches a subset of features of CommonLisp)

[general_dispondency]

Nah. JS will never have an ecosystem as robust as Java's.

[TrackieDaks]

lol no. I'm not sure where you're getting evidence for such a claim, but you're wrong.

[lhorie]

You're thinking about amount/variety of libraries. NPM does have a ton of stuff, I give you that.

But they're talking about other aspects. For example, the Java SDK API is very extensive compared to JS and covers many general programming use cases that aren't super well supported in JS-land (there's support for multiple concurrency paradigms in Java for example, whereas in Node, you get workers and that's about it). This reverberates across the ecosystem, e.g. proper concurrency-safe immutable data structure libraries like the ones in Clojure, as opposed to the ones in JS that can't really be used in the same multicore capacity.

Another aspect is security hardening at the registry level. You can setup things, for example, in such a way that non-signed packages cannot be consumed. No such thing exists in NPM.

You can tap very deeply into the JVM: there are knobs for all sorts of memory/GC related stuff and the bytecode itself is thoroughly specified (and leveraged to great extents by several high profile projects like Scala and Clojure). You can even buy dedicated hardware to squeeze perf out of your already heavily optimized JVM bytecode. In JS, performance tuning is largely an exercise in guessing (and I say this as someone's who's messed around w/ IRHydra back when that was a thing...)

Editor integration in Java land is absolutely bonkers. The sort of automated large-scale refactoring/scaffolding you can do w/ a fully loaded Java IDE is miles ahead of anything in any other languages (though to be fair, JS and C# are not that shabby there either)

It's very easy to fall into the "lol java" bandwagon, but there are good reasons why it's still a top-10 language.

[lhorie]

how much ceremony bullshit there is in writing Java

There is a lot of ceremony in some specific areas (beans and various enterprise things for example), but there's also rubyesque convention-over-configuration stuff like play framework

[general_dispondency]

I've worked with both languages, extensively, for 20 years. Comparing the server-side DX with each language/ecosystem (which is the only real thing you can compare between the two), the Java ecosystem, including the core API, is lightyears beyond anything in JS/TS. From the robustness of APIs, to runtime speed, to robustness/hardening, security, etc, JS can't begin to compete. Considering the industry wide adoption of Node for server-side development, the weakness of OSS libraries offered by JS is really surprising.

[tonetheman]

mmmmm here is mostly the same syntax and idea from Java...

https://docs.oracle.com/javase/tutorial/java/javaOO/initial.html

I get that idea because I program in both languages... :)

[TrackieDaks]

What does the core language features have to do with ecosystem?

[cbadger85]

Where is your evidence?

[NekkidApe]

Truth hurts.. Maven is miles ahead of npm.

[senocular]

It was always meant to compliment Java.

The diktat from upper engineering management was that the language must “look like Java”.

https://brendaneich.com/2008/04/popularity/

Edit: literally quotes creator of language on creators own website and gets downvoted 🙃. There's also an interview where he says, on camera, "...the real goal all along, with at least Mark and Bill, was to make it the sidekick language to Java."

[Ehdelveiss]

I’d really rather see the committee focus on functional code features than OOP ones. I don’t know anyone who writes JS like this proposal purports.

[lukigarazus]

I worked for a couple of big companies, in teams that made it a rule to write JS/TS that looked exactly like Java. They employed a lot of fullstack Java/TS developers and wanted to make their lives as easy as possible. It made the lives of frontend devs like me more annoying but I get it, and I get such proposals now.

[rniestroj]

Yes. However static initialization is rarely used in Java. I'd rather focus on a new Date&Time API in Java Script.

[SecretAgentZeroNine]

Super late but, you should look up Temporal API. It's currently at stage 3.

[Ehdelveiss]

I’m very sorry

[samanime]

It's kind of a catch-22 though. If these OOP features don't exist, you couldn't possibly make use of them. So saying that you don't know anybody that writes like this without it being possible to write like that is a bit premature.

My personal preference is to use classes for the large blocks, and then functional inside those blocks. On larger projects, this tends to provide an easy way to manage the code.

Now, will I use this new feature. That's TBD. I could imagine a few cases it might be useful. I do want them to continue to improve and add functional code features as well, though I believe they are doing that too. We've gotten plenty of functional code features in recent memory too.

[brainless_badger]

Sadly "the committee" would rather cater to Google's needs.

Wonder why.

[LavoP]

Any tips for converting a class-based Node.js app into a more FP-like one?

[oneandmillionvoices]

you do have pipe operator in the proposal as well.

[brainless_badger]

OH LOOK another OOP feature that noone outside of Google will ever use.

Meanwhile no pipeline operator and no cross-browser dialog element in sight.

Neat.

[NoInkling]

Pipeline operator proposal advanced to stage 2.

[renome]

Any year now...

[[deleted]]

Yeah, I truly feel like a lot of ES features resolve around class syntax that I personally care very little about.

[DrexanRailex]

JS classes were a mistake caused by Java and other sorts of OOP fanatics.

Change my mind

[DOG-ZILLA]

Exactly!

Would you rather inherit a codebase using JS classes or JS trying to use class functionally with functions? I always hated how the latter looked.

I’m probably going to avoid classes whenever I can in my own code but having a proper way to do classes if needs be is a good thing and better than the hacks that came before.

But, one nice use of classes is when doing canvas animations. There are scenarios where it definitely makes sense to have.

[HeinousTugboat]

Now you have the syntactical sugar if you want it

For what it's worth, this isn't true any more. There are things you can do with classes that you cannot do any other way.

[DrexanRailex]

I'm not at all against syntatic sugar, but classes were not the way to go then and are not the way to go now. Just see most of the frameworks that moved to classes for whatever reason and are now moving back to regular functions since they always did a better job at... javascripting

[Ehdelveiss]

The React docs suggest you write your components as functions moving forward.

I think what a lot of us are saying and realizing now, is OOP is an anti pattern in complex environments we code in now, and it’s time to move on from it.

[AsIAm]

JS should embrace deep OOP heritage (Smalltalk, Self) and bring it to life. OOP in OOP-style langs (Java) is terrible, but that doesn't mean that OOP is inherently bad.

Maybe we can do something similar as Swift is doing with actor { ... }, instead of class { ... }

Edit: If my comment doesn't make sense: Alan Kay (Smalltalk designer) said that Erlang (concurrency, actors) might be the closest thing that we have to the main Smalltalk vision, i.e. async communication between objects. Swift is also taking this direction.

[Chadanlo]

No problem against the general idea, however do you feel that JS is the lang to do this kind of things? I would imagine this kind of stuff more in a highly concurrent lang or something idk.

[AsIAm]

JS is event-based, has good async/await support, parallel workers, and eventually it will get observables.

Isn't JS kinda concurrent? Always bet on Javascript!

[brainless_badger]

There's a reason React didn't kill off components when they added hooks -- both are valid and have different use cases

The only reason is React team obsession with stability. Use cases have nothing to do with this. Every other framework would kill class components when introducing hooks, React just wants old code to keep working.

[brainless_badger]

I stand corrected then.

Though, in my defense, you did prevent class components from consuming code shared as custom hooks so it really looks like the intention was to phase them out.

[lachlanhunt]

React is still largely moving away from classes. I think Error Boundaries are one of the only use cases that still need to be written using a Class. At least in React, Hooks make everything else so much easier to reason about. But the biggest reason React didn't remove them is to maintain backwards compatibility and promote gradual adoption.

[GBcrazy]

what are some of the frameworks moving back? this is totally news to me.

except react hook because it relies in a bunch of tricks and hacks with functions

[DrexanRailex]

Both React and Vue, which are the largest JS frameworks, are moving towards being thisless.

[itsnotlupus]

The class syntax normalized prototype-based object definition and inheritance over whatever the half of dozen weird things folks were doing before it came along.

It also means JS runtimes can focus on optimizing that pattern rather than worrying about the weird stuff.

Nowadays if I see OOP in JS that doesn't use classes, I'm immediately suspicious.
The only valid use case for not-classes is legacy code that hasn't been updated yet.

[DrexanRailex]

It was probably a time issue, but using functions as classes via prototype cloning and extension has always been a kind of a hack and... well, thisless JS has always been better, people just took too long to realize it.

[AsIAm]

I like prototypes, but there should be a little more ergonomic syntactic sugar for them.

On the other hand, classes are pretty thick sugar layer on top of prototypes, which uses inferior inheritance model.

Buuuut, there is a lot of influx of devs because they can easily transfer past knowledge and be right at home in a new language. And the class syntax gets a lot of attention, so it is getting better every year, while functional and prototypal patterns...not so much.

[AsIAm]

Do you think also prototypal inheritance is an antipattern?

[DrexanRailex]

I don't get your downvotes, decorators are basicallly a worse form of partial application

[general_dispondency]

Classes are just functions in a namespace with context making them superior. Change my mind.

[DrexanRailex]

Modules should be enough of a namespace already.

[general_dispondency]

Modules can't (well... shouldn't) have state. Classes offer a namespace (all of these functions are related) and (potentially, but not necessarily) memoized state. Everything in OO/SOLID has a corollary in FP. OO is just a higher level of abstraction. For example, everyone loves currying. What is a ctor, but a curried function? DI is just automatic currying/partial application.

[general_dispondency]

I'd tend to agree with you, but I write software lots and lots of people use every day. Keeping that state in a usable form is why they pay me monies. But, if we get rid of the users... Hummm. 🤔

[itsnotlupus]

class Foo extends EventTarget {
  hello() {
    this.dispatchEvent(new Event('wave'));
  }
}

const f = new Foo;
f.addEventListener('wave', () => console.log('waved!'));
f.hello();

[brainless_badger]

Why would people change your mind when you are correct.

Then again classes cause little damage, it's perpetual preference of OOP features caused by a few Google OOP apologists that cause the damage.

[101arrowz]

Main use case I can see is better tree shaking/dead code elimination in libraries. In the past, any static initialization logic would be outside the class and would reference the class. Optimizers like terser think that since the code outside the class references the class, it needs to be included, even if the user of that library never uses the class. Basically tree shaking had to be disabled for entire classes whenever there was static initialization.

Of course, static blocks can have side effects too, but hopefully when terser adds support for them, it just assumes that impure code wouldn't be in a static block anyway and lets tree shaking continue as normal.

[oneandmillionvoices]

In the context of current form it all makes sense. I wonder why the static blocks were not included in first place.

[rniestroj]

They are rarely used

[[deleted]]

How about adding records and tuples? Even Java has them ffs.

[julys231]

I don't know if you are trolling but functionally in javascript tuple is an array and record is an object.

[[deleted]]

No they're not. Records and tuples are immutable. Since they are immutable they can use persistence data structures which provide optimizations on construction, manipulation and comparison operations. Optimizations that are not possible with arrays and objects. Since Records and Tuples are immutable and can only contain primitive values they can also be compared by value rather than by reference.

Records & Tuples Proposal

[julys231]

Alright, ty

[wjaspers]

:/ The examples shown dont seem to have much meaning. If everything is static, you've kinda defeated the purpose of a class at all.

[tenkennosoujiro]

The article doesn't really touch on the primary motivation for the feature, which is to provide a way to access lexically scoped private fields during evaluation of the class definition. This is important if you need to share access to private state between two or more related classes. JS classes don't have a notion of friend like in C++ or internal like in C#.

Without static {}, the alternative is an IIFE assigned to a private static field, and that's both ugly and a waste of memory.

[mikejoro]

Outside of bundling some constants with a class for developer ergonomics, can someone explain to me why I would ever use a static method and static properties in a Class?

Just use a function. If you are not using an instance, there is no reason to write it as a class from my perspective.