Chrome DevTools in 2016 and Beyond | Hacker News Reader

Chrome DevTools in 2016 and Beyond

developers.google.com

183 pointsrayshan56 comments

Very happy about debugging Node.js in DevTools. Hard to imagine any third-party debugging applications having that amount of features and polish...

I usually try to pop into the debugger from within unit or integration tests, but have found this to be very slow and unreliable when doing it over a port. Have you found your experience to be different?What is your setup to debug mocha.js (or another framework) tests in chrome?

You should give VSCode a try. I was pleasently surprised about the quality of the debugger. A part from the UI I didn't have any other complaints.

If you run your node code from electron you already have access to DevTools. It's really useful.

Is there a way of doing a long running log of all network, page load speeds, etc. in Chrome and store it in a reasonably efficient format? Like a perfmon/tracer for the browser.

I ask this because I've been trying to track down an issue - probably caused by an ad on a news website - where Chrone pretty much freezes up on all processes. Whilst I can (and have) worked around it by installing uBlock Origin in browsers I'd really like to know what is causing the problem. I can't produce it locally so I'd like to get a log of all things that occur on Chrome over the course of a day.

I'm not sure if this would be of any help, but maybe - so check it out:

https://github.com/kdzwinel/betwixt

Cool to see node-inspector go full circle, from cleverly re-purposed debugger UI to officially supported product.

They mention "Progressive web apps" and link to some info, but I can't figure out what the difference is from a normal webpage. Do they mean "web apps that use some stuff that was recently added to most modern web browsers"?

Generally, a "progressive web app" is something that behaves a bit like a regular native app, when the browser supports it and user allows it. This includes using serviceworkers to cache data for offline (and low bandwidth) use, making a home-screen icon that launches a standalone (from the task switcher perspective) window with no browser frame, and so on.

Pretty much what I thought, thanks!

I'm a fan of the concept, hating apps that could easily have been webpages (public transport apps are often a good example), so it sounds like a good idea to give this a name and promote it. It's too bad that this name sounds like Microsoft came up with it in the early 2000s, but oh well.

It's an awesome idea and one that is actually not too hard to implement, at least partially. Problem is browser support of the APIs, with Safari lagging behind.

Yah, the tricky bit is safari access. I'd love to put a bunch of time into using service workers, push notifications, and so on to make an app-like experience for my users (it's a forum / social network thingy for teachers), but mobile safari really puts a crimp in those plans. Instead I have my own homegrown cache and other hairy tricks that are nonstandard, but work on safari.

It's a laundry list of enhancements that are usually not in any way critical to business and product requirements, and whose absence will likely not be noticed by many users. Great to have and I support the idea 100%, but this stuff is usually the first to get cut when launch is looming, and for good reason.

According to google a progressive web app is a website that progressively becomes an app the more you interact with it.

So I guess at first visit you get things like service workers and notifications. Then after like 5 or so visits you get to install it to the home screen and the address bar optionally gets hidden or played around with or something.

It used to be 2 visits in 5 min (assuming web manifest, https and service workers are enabled).

But, I guess, these things are subject to change.

The definition of "Progressive Web Apps" according to Google is on https://developers.google.com/web/progressive-web-apps/ and https://codelabs.developers.google.com/codelabs/your-first-p...:

"A Progressive Web Apps is:

* Progressive - Works for every user, regardless of browser choice because it's built with progressive enhancement as a core tenet.

* Responsive - Fits any form factor: desktop, mobile, tablet, or whatever is next.

* Connectivity independent - Enhanced with service workers to work offline or on low-quality networks.

* App-like - Feels like an app to the user with app-style interactions and navigation because it's built on the app shell model.

* Fresh - Always up-to-date thanks to the service worker update process.

* Safe - Served via HTTPS to prevent snooping and to ensure content hasn't been tampered with.

* Discoverable - Is identifiable as an "application" thanks to W3C manifest and service worker registration scope, allowing search engines to find it.

* Re-engageable - Makes re-engagement easy through features like push notifications.

* Installable - Allows users to "keep" apps they find most useful on their home screen without the hassle of an app store.

* Linkable - Easily share via URL, does not require complex installation."

After 5+ years of developing in Chrome Dev tools, I switched to Safari 2 weeks ago (Mac) and couldn't be happier. Chrome has become bloated. Ever notice CPU fans ramping up? Only while Dev Tools is open. Memory hog is an understatement. Furthermore, while Chrome's light, prebundled Flash was an asset 3 years ago it's now a liability: most websites now gracefully fallback to HTML5 video. Safari's upcoming leading edge standard support announcement makes it a candidate for best dev browser. (Hint: try Safari's Responsive Mode)

Many news sites insist on Flash still. The shitty thing is that if you use the Developer menu in Safari and change user agent to iPad Safari they often play the video using html5.

That's by design. Please read the "Are you planning to add support for Safari on Mac OS X?" bit on http://www.bbc.co.uk/blogs/internet/entries/8be5501d-43e7-4b...

Is the profiler still tracing instead of sampling?

I once lost a day optimising frequently called JS-methods only to realise that the profiler caused the time spent there.

I switched to Safari 2 months ago for the same reasons as you did. Definitely feels better speed-wise. Also with iCloud keychain I decreased 1Password usage.

For development though, I still can't get use to Safari's developer tools.

Page loads feel faster in Chrome for me, but yes, the dev tools are much cleaner. There are at least worth a second look if you can't find the bug in chrome.

It's ironic that scrolling stutters so much on a Google Developers page when using Chrome on Android (51.0.2704.81). Inertial scrolling is broken too.

I rarely have this problem on other sites. It usually only occurs on Javascript heavy sites (disproportionately frequently on Google sites using that Material UI toolkit).

I'm using a Samsung S7, but had this same issue on my Nexus 6.

the last part of that where paul irish live edits sass looks pretty awesome! good job chrome team!

I'm glad to see Css source diffs in there. My workflow consists of tweaking Css in dev tools and then updating source. I've found that if I map directly so Devtools updates the source file I get lost very quickly. Incidentally I'd be interested in knowing of better ways of writing / debugging css.

http://livereload.com/

slowly the browser is becoming an JS IDE, and that's nice. Ctrl-Shift-I can become the "READY" prompt of the C64. The "next thing" is CDT auto-saving your changes to css and js for a website, and optionally re-applying them on future browsing.

Excited to see better support for App Cache and Service Workers. I still have a bad taste in my mouth from trying to integrate them into one of my applications.

AppCache is no more, deprecated, dead. Luckily.

Probably not a good answer, but if you use Webpack, Service Worker support is a plugin away:

https://github.com/NekR/offline-plugin

Scrolling is broken in Safari on this page. Maybe the page authors should spend less time in the Chrome dev tools and more in the dev tools of other browsers.

Safari is the new IE.

They really are doing themselves a long term disservice by letting this meme be absolutely true.

Hoping for the day I can use Service Workers in all mobile browsers.

Scrolls fine in Firefox, Edge, and IE11, so yeah. It's Safari.

Scrolling works fine in Safari unless you override the native functionality with a buggy/insufficiently tested script.

I'm glad these folks spend their time on Chrome dev tools rather than catering to the users of inferior browsers who expect people to invest extra energy catering to their preferences.

Edit: This may help: https://www.mozilla.org/en-US/firefox/new/

Whilst the issue may not be the fault of the web designers, there's not really any need to call Safari inferior. It's probably a bug, all browsers have them.

My main issue, FWIW, is not that Apple don't fix bugs - it's the long timeframes they take between releases!

Rarely is any description 'needed', but in this case it is 'helpful'. The parent seems to be unaware that Safari has, over time, become inferior (relative to the other popular browsers) increasing the likelihood that the problem is with safari rather than with the site. Being unaware of the inferiority of safari, he didn't even try another browser. Simply knowing that its a safari bug may not be sufficient to maximize the efficiency of his problem solving strategy in the future, as he may brush this off as anomalous. Knowledge that others have found safari increasingly buggy and inferior makes it more likely the parent may adopt a better strategy, such as 'test with another browser first'

What, specifically, do you consider inferior about Safari? I'm genuinely curious - I use Chrome, Firefox and Safari regularly and I find Chrome and Safari to be of equal quality. And I notice bugs in Chrome every now and then, but with both browsers I find it pretty rare these days.

Well, as a for-example, safari's support for indexeddb, service workers, push notifications, and just about everything that makes progressive web apps interesting is pretty lacking.

As another for-example, I was able to hard-crash safari on ios by setting some CSS attributes on the scroll track about eight months ago - like literally a web page with css that altered how wide the scroll bar track was could CTD safari on ios.

As another for-example, KeyboardEvent.key isn't supported in safari.

As another for-example, http://caniuse.com/#compare=chrome+51,safari+9.1,ios_saf+9.3 and scroll down. Battery Status API, Fetch API, Proxy Objects, Shared Web Workers, on and on. The "modern" web as a good platform for interesting progressive apps is passing safari, in particular iOS users, by.

One assumes a motivator here is the app store: apple's walled garden approach is fundamentally incompatible with web apps gaining all these APIs, whereas android's (relative) openness means Google is less uptight about people deploying apps without going through the app store approval process.

My view is that Safari is leading in privacy and lags in everything else. Meanwhile Chrome absolutely leads in security while Firefox leads in standard support.

I use Chrome for work and Safari for casual browsing. Safari definitely has better tab management (tab expose). I am also sad that Firefox UI looks stale. Their settings & options window look like it hasn't changed since initial release.

The settings window changed - it is now a full screen tab.

In any event, Safari is perfectly capable of scrolling a page.

You certainly have made a lot of assumptions about me. I did test in other browsers - Chrome, obviously, and Firefox. But the fact that it works in Chrome and Firefox doesn't excuse the fact that it doesn't work in Safari. I'm a web developer, so it's my job to make things work correctly in all the browsers, Safari included, so from my perspective the creator of the page did a bad job.

Worse, it wasn't something fancy that it's understandable isn't supported in older browsers - it was scrolling, something that literally every web browser ever has been able to do.

Finally, as a web developer and as someone that has used Safari as his primary browser for many years, I rarely have an issue with Safari being "buggy and inferior". You may not get cool new APIs first, but Safari is usually pretty solid and bug-free with the ones it does support.

We will be fixing it. It was a bug in Material Design Lite and we need to upgrade.

You have a shitty attitude.

How can you seriously think that Google developers not supporting other browsers than Chrome is ever a good thing? We are already headed quickly enough towards a Chrome monopoly and Google abusing their dominant position on the internet to make other browsers look bad isn't making that any better.

> expect people to invest extra energy

Funny you use that phrase, because that's what Google expects me to invest to use their bloated excuse of a browser.

I mainly use Safari since it has such a performant UI that doesn't chew up battery-intensive CPU cycles all the time.

While we're mentioning bugs, there is a pretty large header misspelling on the site with "Progressive Web Aps" (should be Apps)...

It breaks in almost spectacular way: https://vid.me/hPye

I really wonder what really causes it.

We will be fixing this. There was a change in safari that busted our material design lite usage.

FYI: It still doesn't work in Safari(9.1.1)

NodeJS and Chromium have complete different debugging API's. It would be cool if they where the same, so you could reuse the debugging tools on both platforms.

> Thanks to the V8, DevTools, and Google Cloud Platform for Node.js teams, you can now use all of DevTools’ powerful debugging features to introspect a Node.js app.