Yang Guo @[email protected]

We’ve identified and fixed a bug that caused considerable lag for some users of Chrome DevTools when trying to inspect elements. A fix is being rolled out with Chrome 143.0.7499.109 and later. 🐢➡️🐰 We are sorry about any interruptions to your workflows.

We just released version 0.5.1 for the @ChromeDevTools #MCP server , and it's a big one for compatibility: we've added *Node.js 20 support*! We saw that many of you were running into issues with older Node.js versions. github.com/ChromeDevTools…

We may have mentioned DevTools at #GoogleIO ... just a few times → goo.gle/4mRPvO7

✨ More Gemini is coming to DevTools! ✨ Try the new experimental AI assistance panel in Chrome Canary 131 and later to get help understanding layouts and debugging your CSS. Learn more at goo.gle/devtools-ai-as…

@JoyeeCheung @fabiospampinato @43081j @_gsathya @marvinhagemeist @bmeurer 😂

@hashseed @fabiospampinato @43081j @_gsathya @marvinhagemeist @bmeurer Indeed, actually the DevTools would also reset the async call stack depth to 0 but Node.js is not disabling the hooks properly because of...a typo 😂 fix in github.com/nodejs/node/pu…

Fun fact: Every Promise that is created is affected by this overhead in Node. Literally every Promise.

@JoyeeCheung @fabiospampinato @43081j @_gsathya @marvinhagemeist @bmeurer I think we disable the Debugger domain when profiling.

@fabiospampinato @43081j @_gsathya @marvinhagemeist You could disable it in the DevTools settings. I guess by default it assumes that you are trying to debug and therefore sends Runtime.setAsyncCallStackDepth even when you go straight to the performance panel. Maybe the UI can be tweaked to send it differently? @bmeurer @hashseed

@Jack_Franklin drinking some Scottish whiskey right now 🥃

@hashseed Not for very long at this rate 😂😂😂

Really appreciate Scotland coming along to make up the numbers

DevTools united at @CSSDayConf! It was wonderful to collaborate and discuss web debugging together, cheers to the future of open web 🥂 @nicolaschevobbe @razvancaliman

@rauchg I agree with the general sentiment, but in case of the English language... Wasn't it mostly gunboats and redcoats?

Open source is how you win

@cramforce @v8js Thanks for the gesture. I no longer work on the V8 team, and I think the V8 team deserves that cake :)

@hashseed @v8js PS: Could you DM me your work address? I'd love to send a thank you cake!

The 90s were calling and we answered. Lots of electricity being saved here. Thanks to the @v8js team for shipping bytecode support so many months ago. I'm so happy to see it deployed in a serverless environment.

@cramforce @v8js You are right. The startup snapshot has more constraints. For snapthsotting next.js after boot Node.js should already have implemented support iirc. Might still be worth it.

We *could* use a snapshot. The benefits of bytecode are that it just works without any cooperation of the software (with respect to open files, sockets, etc.). I think realistically, we could only reliably snapshot after next.js (for example) boots but before it loads user code. Additionally, startup time is extremely sensitive to the size of the function, and snapshots may be at the wrong side of that trade-off. It's definitely something we're interested in, though.

@fabiospampinato @erikcorry Yup. Benchmarks.

@hashseed @erikcorry Whatever it is at the end of the day I think in this particular case we may be talking about the same exact sequence of bytes, so I'd expect pretty much the same performance. Uint8Array probably received less attention I guess.

The performance of (A) String.prototype.indexOf and (B) Uint8Array.prototype.indexOf seems to vary *wildly* across engines, and it's a bit puzzling to see these numbers: - Chrome: (A) ~300ms (B) ~850ms - Safari: (A) ~1850ms (B) ~1950ms - Firefox: (A): ~4000ms (B) ~136000ms

@robpalmer2 @fabiospampinato @addyosmani @ChromeDevTools Wouldn't the allocation sampling profile do the trick?

@hashseed @fabiospampinato @addyosmani @ChromeDevTools The idea is to find out accidental sources of short-lived objects that incur high GC perf costs. The fact that they cross a timing boundary is just more signal on the cost side.

In @ChromeDevTools you can now find memory issues more easily. We added new filters to "Memory" to find duplicate strings, objects retained by detached DOM nodes and other reasons when taking heap snapshots.

@tunetheweb Well here you are, still alive :)

So apparently 15 years ago day I was eating interesting things in the Amazon. With all the bravery that doing that deserved… (Better with sound, but almost as good even without it)

@robpalmer2 @fabiospampinato @addyosmani @ChromeDevTools Trying to allocate objects to get the right GC timing seems like a bad idea though?

@fabiospampinato @hashseed @addyosmani @ChromeDevTools I guess you probably care most about the objects (and their creation sites) that survived one full GC but then died soon after.

@fabiospampinato @addyosmani @ChromeDevTools Yes, this could be implemented. Do you have a use case for knowing which objects die?

@hashseed @addyosmani @ChromeDevTools But it could be implemented differently, no? Like what's stopping not actually freeing anything when under a particular mode, so that those objects could be inspected, and then actually freeing them when exiting this special mode?

During industrialization, machines replaced manual work. Now it looks like machines could replace mental work as well. If the consequences of AI even remotely resemble industrialization, we are in for a wild ride. Productivity, job market, social security, society, world order.