Chrome DevTools: A Glimpse into the Future and RAIL Profiling | Hacker News Reader

Chrome DevTools: A Glimpse into the Future and RAIL Profiling

developers.google.com

76 pointsrayshan26 comments

Just opened the dev tools in Canary. Not a big fan of that "mobile-first" device bar to be honest. As a primarily desktop dev, the previous device mode worked better for me (enable it when you need it, disable it when you don't). I hope we can at least make it optional in the final revision.

Everything else looks great though, keep up the good work!

We're working on it! We heard this feedback a few times. Our intention is to make mobile the default in DevTools, but we don't want to make the experience worse for people building Desktop sites. So we'll come up with a better solution. Stay tuned!

How about persisting the last state? So if a user switched to desktop, keep it as desktop when they re-open devtools.

The mobile device bar is particularly annoying while working split screen on laptop; vertical space is already very tight.

As it is right now, you can choose whether you want it split vertically, horizontally, or undocked with the dock button if you click and hold. This is just a different set of defaults if I understand correctly. It should be trivial to set it to how you want (and currently it remembers your prior preference, so hopefully that continues).

if you move the split from the bottom to the right side, it fits great... Unless I'm missing something?

I typically have sublime on the other side of the screen and the dev tools docked to the bottom - http://i.imgur.com/JByAoiK.jpg

Am I the only one still doing most of my front-end work for Desktop land? Feeling a little left behind with this announcement.

With the changes, we are pushing DevTools into a mobile-first future where mobile development is the default, and Desktop development is the “add-on”

Author of the linked post here. Definitely wasn't our intention to leave Desktop behind. A mobile-only world isn't better than a Desktop-only world. Thus, mobile first. Start with the most common scenario and build your way up to other platforms.

That being said, I realize that some apps and intranet sites will be Desktop only by design, and that's fine. We don't want to make your experience worse. Any feedback on that front is greatly appreciated.

Is it the most common scenario in development? Seems to me you've got it backwards. You've confused consumers of websites with numbers of developers.

For example I see far more job adverts for internal tools developers, which are going to be by and large desktop only, than mobile-first website developers.

So I'd have thought the number of desktop only web app developers vastly outnumber the number of mobile-first web developers. I think you're wrong with the word 'some'. Most is the word you should be looking for.

Don't forget you're emulating a phone without touch. It's useful, but it's only part of a mobile testing process. So you're making what is a fairly broken process the 'focus', which seems pretty odd.

Mobile is also feature poor compared to desktop so generally needs less testing. It's the less intense part of any site because of the form factor. That's why you're not playing Fallout 4 on your mobile, you've got a little companion app for it instead.

Finally, for most mobile websites there will be a desktop only admin section. And it's desktop only because it has huge tables, with lots of sortable columns. On multiple pages. Common admin interfaces found in any website or app. So while a desktop site can often exist without a mobile component, it's rare for a website to exist without a desktop component.

Speaking of mobile development, something that's been annoying me for a long time is that while you can "emulate" the devicePixelRatio of a mobile device, it doesn't actually seem to do anything meaningful.

For example, my phone has a resolution of 1080x1920 and a dPR of 3, so the viewport size is 360x640.

If I set these properties in Chrome Dev Tools, I just get a 360x640 rendering out of it. I'd like to be able to get a proper 1080x1920 rendition of the device screen too! It doesn't matter that it will look absolutely enormous on my desktop screen, I just want to make sure that my code and styling actually works like I want on it. I really shouldn't need to use an actual device for something as simple as this.

I'm not entirely sure what's meant by that comment. The form factor appears to be sticky, so the first time you just click the desktop icon instead of the mobile icon and it will always open in desktop mode.

That said, don't assume your users aren't using mobile browsers :) Based on the videos, that's the intention behind the change. A non-sticky setting would be annoying, but putting it front and center (rather than buried under emulation settings) and having it selected the first time you open dev tools will hopefully get more web site developers thinking about this stuff earlier in the development process.

nope, you are not. Chrome is a great intranet application delivery platform.

Same here. Been at a couple companies that consider Chrome part of our app's stack.

If you want to know what RAIL is without watching a video: https://developers.google.com/web/tools/chrome-devtools/prof...

Goodness gracious, you'd think GOOG could have put that link in the video description.

Thanks.

"Didn’t give up on printing yet?" I appreciate the sentiment, but all of my customers love printing. Good browser support for print-specific styles allows me to avoid doing unpleasant things like rendering an SSRS report to PDF and then printing. At least for LOB apps, printing is going to be around for a while.

Unfortunately, until the Google team can be bothered to address pretty critical issues like columns not being printable [1], I have little faith that they really care about print support at all. For most people, printing is a thing of the past, and I'm grateful for that, but certain use cases demand it - a site providing educational resources, for example.

[1] https://code.google.com/p/chromium/issues/detail?id=99358

I was hoping that 'mobile first' meant that Chrome for Android was finally getting DevTools.

Instead it means they are going to be tailored for progressive enhancement. Which I hope leads to more developers embracing that approach over creating multiple separately maintained versions of the same site.

You know you can already access Chrome for Android with DevTools via chrome://inspect/#devices ? Note: You may need to run adb devices to get your device to show up

There is also the rather wonderful WebIDE in Firefox which lets you connect to a range of iOS and Android browsers via a single interface

Yes, I already know about the remote debugging tools.

That's not the same as having DevTools available in Chrome for Android.

I'd love a web console on my android.

A lot of the design tools are nice, but what about persisting the tweaks we make on the page?

What if we're using a build process (i.e. Sass, ES6 transpilers, etc)?

I've tried using Workspaces in the past, and it was just not a very pleasant experience. So much potential, though!

Not exactly about the DevTools, but, I work with chunky SVGs in Chrome and that latest version feels completely different. It's always a little like playing whack-a-mole to juggle performance / user experience when a new version comes out but this version feels really nice and fast so far. Kudos to the Chrome team!

I wouldn't call it "mobile first" until devtools becomes available in Chrome browsers on mobile devices

Layout Mode sounds really cool, I wonder if they'll be able to expand that to more of CSS.

Reply on news.ycombinator.com