Following my entries on PhpStorm and Docker, here are my notes on the state of browser dev tools. When working on a website, especially if you’re doing full-stack work that spans design, backend and frontend code, the browser and its development addons become an integral part of your toolset. Browsers provide a lot of functionality that you just won’t find even in a powerful IDE like PhpStorm.

1. Prerequisites

In order to make full use of browser tools in a way that ties back to your code, in most cases you need to generate CSS and JS sourcemaps. This is to make sure compiled/concatenated/minified CSS/JS files point back to their original sources, especially if you use a CSS preprocessor. You can do that with a task runner, with PhpStorm, or with a task runner managed from PhpStorm.

It is beyond the scope of this entry to explain this in detail, so if you’re not familiar with these concepts, read:

• Introduction to JavaScript Source Maps [HTML5Rocks, 2012]
• Source Maps 101 [Tuts, 2013]
• Gulp-Sourcemaps

Here’s a video showing source maps in Chrome:

2. Mozilla Firefox

2.1. Vanilla Firefox + Firebug + CSS-X-Fire

The CSS-X-Fire PhpStorm plugin allows CSS edits made in Firebug to be caught back by PhpStorm where you can save them in the source LESS file with one click (or discard them if you’ve changed your mind). In other words with it you can go back and forth between PhpStorm and Firefox, edit LESS/CSS in either program, and get the changes reflected or saved seamlessly.

After some tinkering with CSS-X-Fire, I’ve found it works best with “Currently opened files” checked, which means you need your source LESS/SCSS to be opened in PhpStorm.

This is great in its own right, though the process to find then edit CSS selectors in Firebug is not very streamlined, because you have to go back and forth between Inspect (which opens the HTML tab) and CSS (where you have to search for your class). Since I’m willing to work hard to get tools that will let me be lazy later, I kept looking for a better way. More seriously, I’m trying to remove all these grains of sand that add up and in get in the way of establishing and maintaining flow/zone.

2.2. Firefox Developer Edition

In search for the perfect modern toolset, I revisited Firefox as a browser for development. Like many people I gradually moved to Chrome over the years, after suffering from memory leaks in Firefox and see that browser lose its edge. So I’ve installed Firefox Developer Edition, which comes with Firebug.next. Indeed, it’s a significant refresh.

However, in the pursuit of our ideal workflow, I tried CSS-X-Fire with it, and unfortunately it’s not supported.

 

It’s a shame because otherwise, it’s clear that the Firefox and Chrome Dev Tools are learning from each other, with some of the cutting-edge functionality shared by both.

Both now do natively what used to require a bunch of separate extensions, from playing with the viewport to test responsive designs, to color picking/eyedropping and more.

These Dev Tools are full-fledged suites nowadays, feature discovery and developing the corresponding “muscle memory” to use said features become a real challenge.

See:

• Revisiting Firefox’s DevTools [Smashing Magazine, December 2015] makes a solid case for FF.
• Review of the new Firefox browser built for Developers.
• Firefox Developer Tools.
• DevTools community.
• Patrick Brosset’s Youtube channel. Patrick works in the FF dev tool team, and is yet another Frenchman involved in open source.

3. Google Chrome

3.1. Chrome Dev Tools: A Promising Tease That’s Not Yet Fully Baked In

There no directly-equivalent functionality to what’s done with the Firebug/CSS-X-Fire combo native to Chrome Dev Tools. You can set up persistence with the DevTools Workspaces and map local paths to network resources, but this comes with several limitations and doesn’t feel quite as seamless. Changes made from the Elements > Styles tab are live previewed, but they cannot be saved, you have to go to the Sources > Editor part of the Dev Tools to be able to save changes back to your local file, which is a bit redundant with using an IDE.

The Chrome dev team realized that this workflow was a bit more convoluted than it needs to be, and introduced the Quick Source pane  to alleviate precisely these back and forths. I installed Canary to test this, unfortunately the changes I make in the Style panel are not reflected in the Quick source panel. I triple checked my mapping settings, enabled Source Diffs in Experiments, but the bidirectional magic demonstrated back in June 2016 doesn’t work for me as of Canari 56.  I think it’s still limited to SASS, but I use LESS and I won’t switch to SCSS until Bootstrap 4 gets out of alpha/beta.

The Google I/O video is still worth watching entirely to see where things are headed (some of that functionality is available). The bidirectional workflow is demonstrated by Paul Irish starting 14 minutes in:

And here is Irish’s demo of the latest improvements as of November 2016:

Meanwhile, the Chrome extension for JetBrains IDE support works for live edits from the IDE to the browser but not vice versa. It’s still useful anyway because it feeds Javascript debugging and console info back to the IDE. Note there’s a frustrating, long-standing Chrome bug which prevents remote debuggers from working if the Web Inspector is already open.

3.2. CSS-X-Fire with Chrome

CSS-X-Fire does not exist as a Chrome extension, but there’s a bookmarklet meant to work in combo with Firebug Lite (Chrome Store), which is the best you can get in Chrome, Firebug-wise. You’ll want to black box firebug-lite.js so it does not pollute the console with its own errors.

To find either the Firefox extension or the bookmarklet, make sure to click the question mark in CSS-X-Fire’s tab within PhpStorm, which will open a local web page where the assets can be downloaded. This threw me for a loop a bit because that stuff cannot be directly downloaded from the web.

It does work so you end up with the same functionality you’d get with FF/CSS-X-Fire. Not as nice as using the native dev tools since Firebug Lite is redundant and limited compared to them, but still, pretty sweet.

3.3. Ports and CORS

While trying to get these tools to work, we run into Access-Control-Allow-Origin errors in the console. I first ran into CORS issues with BrowserSync that I solved by using a relative URL in my enqueued stylesheet as opposed to WordPress’ absolute paths (don’t get me started on how WordPress can sometimes be opinionated and wrong). But that was not the end of it.

These problems occur because the Development Death Star we’re putting together is using 4 TCP ports:

1. The localhost’s default port, say 80 (which itself is mapped to whatever port Nginx is set to in my Docker container)
2. BrowserSync’s port, say 3000, which is the one we use in the browser while BrowserSync acts as a proxy back to port 80
3. CSS-X-Fire’s port (6776), which is used to talk back to PhpStorm
4. IDE Support Chrome extension port (63342), also used to talk back to PhpStorm

So we want a more general solution that takes care of CORS, no matter the source of the domain/port discrepancy. I tried to figure out how to enable CORS (hi Monsur!) with BrowserSync, but using the middleware option like shown here does not seem to work with BS set as a proxy. Fiddling with Nginx is another possibility, but it sounds like too much work.

After a little more research, I found this Chrome plugin, which is the path of least resistance to get rid of these CORS issues. (Older online discussions mention the –disable-web-security command line setting but it is no longer supported in Chrome.) So you can have nice things! There’s a similar setting for the PhpStorm extension.

If you struggle with BrowserSync’s proxy/server setup, or if your web server suddenly decides to permanently redirect from BrowerSync’s port to its port (it happened to me with Nginx, no idea why), a simpler setup involves loading BrowserSync’s javascript from your source code. Now you’re directly loading the web server’s port in your browser. Make this conditional in your code, based on an environment variable that tells your whole app whether you’re in dev/test vs. production, which you’ll probably use elsewhere (e.g. wp-config.php or wherever you load server-dependent settings). Also, blackbox browser-sync-client.js in Chrome DevTools setting.

3.4. Keeping Up with the Evolution of Chrome Dev Tools

For now our ideal bidirectional workflow remains elusive, but let’s not focus on the glass 10% empty. As I said, any of these dev tools now do stuff that used to require separate extensions, such as emulating mobile devices/viewports, playing around with media queries and CSS animations, or assessing security flaws. Developers willing to invest in their continuous self-improvement (aka smart people) will want to keep learning new tricks not just in their favorite IDE, but also with their browser of choice.

To learn the ins and out:

•  Addy Osmani’s Chrome DevTools Deep Dive. You’ll see Google continues to iterate, especially to support mobile and speed testing.
• Totally Tooling Tips Youtube playlist Addy manages with Matt Gaunt.
• Official documentation, and updates from the Google Developers Web team.
• Umar Hansa’s /dev tips.
• Coderwall: Chrome [random tips]
• Codeschool videos.
• Egghead videos.

3.5. Chrome Extensions

I’ve already mentioned most of these, but for convenience, here’s what I’m using in one list:

• Allow-Control-Allow-Origin: * – CORS headache medicine.
• Firebug Lite for Google Chrome + CSS-X-Fire bookmarklet – Bidirectional CSS edits.
• JetBrains IDE Support – JS IDE debugging.
• Xdebug helper – PHP IDE debugging.
• Web Developer – Misc tools.
• Emmet Re:view. Dev Tools eventually made many responsive-centric extensions obsolete, but this one keeps an edge, provided you have enough screen real estate.
• Domflags – Create keyboard shortcuts to DOM elements. For persistence across debugging sessions, consider adding “domflag” to the source code generating the elements you’re currently working with. Caveat: doesn’t work well unless the dev tools are in docked mode as opposed to their separate window.

To set up keyboard shortcuts for your extensions, put this in the Chrome address bar:

chrome://extensions/configureCommands

I removed the link to the Live HTTP Headers extension because it got infected with malware. Anyway, a much more powerful alternative is the Fiddler desktop application. Use its process selection icon to limit it to your Canary debugging session, and know all about the http traffic in your web app.

4. Other Browsers

It’s beyond my time budget to look into these, but just for the record, the world is not limited to FF and Chrome:

• Meet the Microsoft Edge Developer Tools. I love that Satya Nadella’s Microsoft embraces community tools such as UserVoice and Github.
• Safari Web Development Tools (wasn’t Safari for Windows discontinued years ago anyway?)
• Opera Dragonfly

5. Putting It All Together

5.1. Project Launch Automation

Let’s put the browser in the context of our broader toolset and workflow. Because I like to optimize repetitive steps, I’ve set things up so that PhpStorm, Docker, BrowserSync, and Canary with Dev Tools are all up and running after pretty much just launching PhpStorm.

Here’s how it goes, from a fresh PhpStorm start:

1. PhpStorm’s System Settings are set to “Reopen last project on startup”, so my current project opens at start.
2. The BrowserSync Gulp task is executed automatically as a startup task when PhpStorm opens my current project at launch.
3. The task triggers automatically a batch file configured as an external tool, just to make sure Docker containers are running.
4. The task then opens Canary+Dev Tools and/or other browsers such as Firefox.
5. DisplayFusion automatically moves and resizes these browser windows exactly where and how I want them. DisplayFusion is on list of software recommendations for productivity.
6. I click the Listen for PHP debug Connections icon in PhpStorm. Sadly macros don’t work in Run/Debug configurations.

The whole thing takes maybe 30 seconds to fully execute, mostly because PhpStorm reindexes projects when it opens them, but think about it, I get a whole Docker-IDE-browser-dev tools up and running from even a cold boot, with very little manual input necessary on my part.

5.2. Save Yourself Some Aggravation and Work in Incognito Mode

Canary is set up to launch in incognito mode with Developer tools opened in a separate window. So I installed just a few vital dev extensions in Canary and enabled them in incognito mode. Here are the command line arguments, which you can also use in a Windows shortcut:

--incognito --auto-open-devtools-for-tabs

Benefits of developing with your browser in incognito mode:

• Keeps your development browser completely separate both from your main Chrome install and from any websites you’ve visited or tabs you’re keeping open.
• The dev tools and console don’t get polluted by a bunch of irrelevant extensions or 3rd-party cookies.
• Don’t struggle because of Chrome’s internal DNS and redirect caching

Canary and its DevTools are set up with dark themes so that they don’t bombard me with white light and stand out visually from my regular Chrome browser. Canary also has the latest and greatest version of DevTools, especially if you enable DevTools experiments.

Make sure to remove the JetBrains chrome extension from your regular Chrome install, otherwise if it’s running JetBrains will interact with it and won’t launch Canary. (Source.) Also, if you want to debug Javascript in PhpStorm, make sure to close the Chrome DevTools first.

If I want to see what the test site looks like in Chrome, that’s a separate job from coding/designing/debugging, and I can always load the site in vanilla Chrome, just like I would in IE or whatever.

6. Closing Thoughts

I mentioned Mozilla’s Patrick Bosset earlier. Read his perspective on Visual Tools —Prototyping in the browser. I strongly agree with this.

Netscape Navigator came with a Composer HTML editor in 1997 – almost 20 years ago! – but why wouldn’t the same piece of software work for authoring and reading? Why code and design separately when what you’re delivering is an interactive visual experience? And why code and design without seeing instantly what the result looks like?

Adobe Dreamweaver let you design and preview in the same environment, but it felt obsolete years ago because it felt stuck in the Frontpage era of static HTML editors with awkward code awareness at best. Isn’t it interesting they just relaunched Dreamweaver as a “modern web design and development tool that has been re-imagined for designers who code”?

The tools will remain in an always-imperfect state because the underlying technologies keep changing, but I’m excited because many of these tool vendors seem to truly get what full-stack web develodesigners need.