Chrome 72 Beta: Public class fields, user activation and more | Hacker News Reader

Chrome 72 Beta: Public class fields, user activation and more

blog.chromium.org

54 pointsfeross28 comments

There is a lengthy debate surrounding private field syntax [1][2]. As a TypeScript user, I prefer regular-JS drop this proposal altogether, rather than use the current syntax. Refactoring and index-access notation become awkward with it.

Anecdotally, the vast majority of serious developers I know transpile to JS.

  [1]: https://github.com/tc39/proposal-class-fields/issues/177
  [2]: https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md

I'm pretty sure transpilation is supposed to gradually adopt something more modern than es5.

I agree overall, but some language/env enhancements (e.g. BigInt) transpile more naturally than syntax-dependent ones like #private.

The discussion seems to be mostly driven by people who are used to a very specific syntax and can't understand why it wouldn't work for a real implementation for private. Nothing will stop these people from keeping their use of "private as documentation only" while others will get their proper implementation of private state that isn't as fragile as the one offered by TypeScript. That last part isn't a dig at TypeScript - it's just that at the time it was the best TS could possibly offer.

I expect that TypeScript will adopt this proposal given that some of the people working on and defending the proposal seem to be part of the TypeScript team.

> Refactoring and index-access notation become awkward with it.

Given that other languages have similar solutions and this actually has more information in the source file, I assume that refactoring will become quicker and index-access will just move to private maps. Adding arbitrary fields at runtime and dynamic access to private fields are both tools with limited value compared to the potential for introducing subtle bugs.

>Anecdotally, the vast majority of serious developers I know transpile to JS.

TIL I'm not a serious developer. I actually think compiling Javascript is a huge barrier to entry to would be devs. I think a development experience of put the code on the page and it runs is a lot better than configuring npm/gulp/grunt.

It truly, truly depends on the conceptual size of the application you're writing. Small components with simple interactions? Use something like Vue without compilation, and you'll have a low barrier to entry.

But if you're writing complex business logic, trying to build pipelines of client-side data whose derivations are fed into a myriad of components, and you'll want things like type constraints, module hierarchies, compiler support for things like JSX to simplify the cognitive load of understanding what a thing-that-outputs-HTML-like-stuff does.

At the end of the day, compiler setup is O(1), and code complexity is at least Ω(N) in how difficult it becomes to understand a codebase. It's worth doing anything you can with the compiler to reduce complexity in large codebases.

Vast majority != you. Unless you're obscenely overweight or some sort of hive mind, I can't imagine OP was suggesting that you're not a serious developer.

I also think you right. Compilers don't always go well with programming inductees. This is why Python and Ruby are so popular as introductory courses. But this is why I think Javascript has done so well because it doesn't _need_ compiling, which is great for new-comers. When things level up and get complicated, enter JS compilers. It's a 'best of both worlds' sort of thing.

>I think a development experience of put the code on the page and it runs is a lot better than configuring npm/gulp/grunt.

The problem is that this breaks down immediately for a million different reasons at any kind of scale with multiple developers, complex dependency graphs, and the need for automated testing. The tooling exists to solve real problems whether you've experienced them or not.

I have to agree with this. The syntactic sugar that has been slowly amassing around JS has been mostly useless in the face of things like TypeScript and Babel reaching ubiquitous usage. It's better off just left to a transpilation target at this point, as everything will be WASM based once that's ready anyways.

Serious question: Why would you use WASM for a dynamically typed, GC'ed language?

>Serious question: Why would you use WASM for a dynamically typed, GC'ed language?

The point is using it as universal bytecode for deploying anything you want. Ideally we could do front end web development with any language/framework combo and just compile to WASM. It seems like that's the future, with things like Blazor getting major support, and that JS will probably mostly die out over the next 5 years.

https://github.com/aspnet/Blazor

WASM always seems like the future until you find out how big the binary is relative to even a meaty JS app when it includes all the code needed to support things like GC or dynamic typing.

> Public class fields

As a TypeScript-user, I hadn't really realized this wasn't just plain, regular Ecmascript yet and thus assumed it had to be something else.

So I had to read the blog-post to see what it was, and find out that I no longer know regular Javascript ;)

I'm having to write JavaScript (ES5) without TypeScript right now & using jQuery. Whew...

The folks who did ES6 upgrade & TypeScript improvements can't be thanked enough.

ES6 is really the main thing that made me stop hating web dev. A long way to go but that was a watershed moment.

Classes don't really exist in JS. They're (mostly) syntactic sugar for OOP programmers. e.g. https://stackoverflow.com/questions/36419713/are-es6-classes...

By this logic what differentiates JS classes versus, say, C++ classes? C++ classes compile down to almost nothing. Non-virtual calls are static dispatch, virtual calls are just an indirection into a vtable.

I suppose the main difference is that in JS the implementation semantics of classes are defined and can be prodded at. Is that really so different though? I think it's just a bit strong to say ES classes "don't exist" because the methods by which they operate can be observed at a lower level.

> virtual calls are just an indirection into a vtable.

Exactly, and `.prototype` is just a runtime and programmable vtable. You copy (by reference) everything from the base prototype and replace (override) every member that you need to. You can even call overridden methods with `BaseType.prototype.foo.call(this, ...)`.

The prototype concept is little more than an annoying implementation detail for vendors to worry about. No use of it other than the `class` pattern ever saw any adoption. It causes more confusion every day than it provided distinct value in the last decade.

With any luck we'll have so completely abstracted over it by ES12 that it won't even need to be mentioned in the spec.

For me they definitely exist in JS. Prototypes are just an implementation detail.

Unfortunately the coming private fields spec is far more messy and will result in typescript having different compile-time and run-time private fields syntaxes.

No public signals from any other browser vendors? No thanks. Miss me with that monoculture bullshit.

The only one that has major implementation changes is the Public Class Fields proposal, which has positive public signals from other browsers:

Proposal - https://github.com/tc39/proposal-class-fields

Firefox Implementation Tracker - https://bugzilla.mozilla.org/show_bug.cgi?id=1499448

Safari Implementation Tracker - https://bugs.webkit.org/show_bug.cgi?id=174212

The others are largely security updates which honestly I'm fine with browsers pushing ahead with. The User activation query API stuff is great and is gonna solve a lot of headaches around misbehaving sites. Safari already has a rudimentary implementation around this with autoplay as well, so this is an effort to standardise some existing "monoculture bullshit".

As far as depreciating TLS 1 and 1.1, I don't think there's anyone out there arguing that that isn't a good idea.

The User activation properties should have been added when they first started restricting apis to user initiated actions.

I said such in the mailing list for the framebusting change to require activation.

Yeah, there's a bunch of nasty code we have which is essentially trying to predict if the window.open call will be blocked (in which case we have to get them to click a button instead to open the window). Once that API has enough adoption we'll be able to remove that which is nice.

Can someone explain what a user activation is? I couldn't work it out from the article or the naming.

IIUC many APIs (e.g. requestFullscreen()) are only callable from JS during a short window of time following a user interaction. The userActivation property allows programs to check whether those APIs are callable, rather than calling them blindly and catching errors.

Is there any standard for the user activation APIs? Changing the signature for postMessage seems like a particularly aggressive change.

Reply on news.ycombinator.com