
Chrome 72 Beta: Public class fields, user activation and more - feross
https://blog.chromium.org/2018/12/chrome-72-beta-public-class-fields-user.html
======
wakeywakeywakey
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

~~~
TACIXAT
>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.

~~~
btown
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.

------
josteink
> 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 ;)

~~~
ordinaryperson
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...](https://stackoverflow.com/questions/36419713/are-es6-classes-
just-syntactic-sugar-for-the-prototypal-pattern-in-javascript)

~~~
jchw
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.

~~~
zamalek
> 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, ...)`.

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

~~~
jjcm
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](https://github.com/tc39/proposal-class-fields)

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

Safari Implementation Tracker -
[https://bugs.webkit.org/show_bug.cgi?id=174212](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.

------
MrStonedOne
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.

~~~
jordanthoms
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.

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

~~~
aravindet
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.

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

