The current behaviour allows you to inspect and make adjustments in the browser. While this is a good thing the boost in productivity is lost when you have to retrace your steps, copy and paste your code, save, reload, realise you didn’t retrieve all of your inspector changes, despair, recreate them again in the browser, meticulously retrieve your changes this time causing your workflow to slow to a snails pace and watch the perceived benefits of in-browser editing vaporise before your eyes, copy and paste your code into your editor, save, hesitate, hesitate a little more, then decide to open a new browser tab and leave the tab containing your ideal design state the hell alone, load the URL, and hope that it works.
Eurgh, I’ve done this so many times!
Jordan raises some quality points in his article. It’s funny how we’re always striving to produce tools and frameworks that’ll help speed up our workflow but then lose those savings jumping between different applications.
I wrote about my build process earlier this year and listed out the tools I use to work. It’d be pretty slick to amalgamate some of these tools into one.
I know some folk like the idea of a tool doing one thing really well but when you’re using 10 or so applications that don’t talk to each other, all these separate processes can become a hindrance.
Hindrance is a bad thing for flow.
Jordan suggests an editor like Sublime Text but with an inbuilt web browser than can be docked to the side. Make a change in the code and it’ll display instantly; all wrapped up in one application. None of this editing a file, clicking save, waiting for CodeKit or Mixture to process the files and then waiting some more for the browser to refresh.
Three apps amalgamated into one
I’m all for processes that reduce friction between me & the final product.