What's New in DevTools (Chrome 68) | Hacker News Reader

What's New in DevTools (Chrome 68)

developers.google.com

70 pointsrbanffy12 comments

I was curious how they implemented the side-effect checking, so I dug my way from the dev tools frontend eventually into v8, where it turns out to basically be a bunch of whitelist checks over bytecode and builtin javascript methods https://github.com/v8/v8/blob/e48d9788a4ef21d3bfffbc691bb02c...

I think Chrome really got traction over FF because of these dev tools.

I used to think "Firebug" was the greatest thing since slice bread when along came Chrome with its dev tools and soon every web developer started switching to Chrome because making sites with it is just too easy. When it comes to the internet I've often seen that targeting the technical users can pay back in many folds.

Also adding new APIs quickly means people end up using the browser just to play with them.

Eager Evaluation is pretty cool! It will help me discover APIs a lot easier. I have two questions about this:

1) what happens when evaluating is going to take a lot longer that usual?

2) why the arguments list hint is using Flow syntax for optional (question mark before argument name)?

https://developers.google.com/web/updates/2018/05/devtools#e...:

> DevTools does not eager evaluate if the expression causes side effects.

Long-running doesn't imply with side effects.

> 1) what happens when evaluating is going to take a lot longer that usual?

Just checked: It evaluates it in another thread - and around 1e6 actions it stops evaluating. There is no noticeable slowdown in the devtools.

> 1) what happens when evaluating is going to take a lot longer that usual?

There's a 500ms timeout (but only when it thinks there may be side effects? https://github.com/ChromeDevTools/devtools-frontend/blob/03f... )

Aside:

It's kind of amusing that "side effects" seems to have become a synonym for "effects". Usually "effects" are things you want to happen, whereas "side effects" are things you don't necessarily want to happen (although they may ultimately prove beneficial.)

If one's type system actually models "effects" as first-class entites -- e.g via monads or capabilities -- then suddenly the distinction becomes much clearer. In typical imperative languages like JS, C or C++ it's clear as mud.

Of course, given that the browser'js JS engine is a VM unto itself it can just speculatively run everything until there's an "effect" and then 'roll back' (or remove the CoW data that was produced) so as to make it unobservable.

This is ingenious practical engineering.

For fans of eager evaluation, there's a VSCode plugin called Quokka that inlines similar functionality as code annotations as you work.

https://quokkajs.com

The youtube channel 'funfunfunction' (@mpj) is where I first learned about the tool.

https://www.youtube.com/watch?v=W4brAobC2Hc (JS iterators explanation using Quokka)

(They started sponsoring his channel several months after he began singing their tool's praises.)

Excited for Eager Evaluation! I can't count how many times I've had to re-rype selectors when exploring the DOM in a project.

Wow BigInt support [1] sweet! Finally 64 bit integers in JavaScript. Proposal here [2].

[1]: https://developers.google.com/web/updates/2018/05/devtools#b...

[2]: https://github.com/tc39/proposal-bigint/blob/master/README.m...

Reply on news.ycombinator.com