Original URL: https://www.theregister.com/2014/08/20/programming_the_web_25_part_iii/

Look, no client! Not quite: the long road to a webbified Vim

Building in the browser

By Scott Gilbertson

Posted in Software, 20th August 2014 08:30 GMT

Programming the Web, Pt. III The most revolutionary aspect of all the changes that have taken place in web development over the last two decades has been in the web browser.

Typically we think of web browsers as driving innovation on the web by providing new features. Indeed this is the major source of new features on the web.

For example, Microsoft releases a version of Internet Explorer with support for iframes, then later XMLHTTP (which Mozilla and others pick up in the form of the XMLHttpRequest) and asynchronous JavaScript is born. Out of that comes the ability to build much more complex web apps, like Gmail.

There is however, another less obvious way in which browsers have been driving innovation, especially in the last five years - by giving web developers ever more powerful developer tools built right into the web browser.

Indeed, it's entirely possible the web has grown more sophisticated in proportion to the sophistication of tools available for writing, testing and debugging HTML, CSS and JavaScript.

Would today's increasing complex and sophisticated web apps be possible without debugging tools available in web browsers? Would today's Web Component driven experiments be possible without the Chrome, Firefox, Opera and IE developer tools? Well, probably they would still exist, but they would be much more difficult and time consuming to build.

Once upon a time web browsers offered web developers a single developer tool: view source.

While view source is a revolutionary tool - I'm not aware of any other development platform in which you can look at the code behind the app with the simple click of a menu - it's a learning tool, not a building tool. HTML, CSS and JavaScript source files can be very instructive, but view source is of little help when in comes to writing and testing your own markup and scripts.

To write and test your own code, particularly JavaScript, you need a way to control the runtime environment of the browser - the ability to insert breakpoints, pause code and step through it line by line to find bugs and improve your code.

The first major effort to give developers that kind of power right inside the web browser was Firebug. Initially an add-on for Firefox, Firebug was written in 2006 by Joe Hewitt - one of the original Firefox creators. There are a few browser developer tools that predate Firebug. Internet Explorer 6 had an add-on that showed the DOM and some other information about the page. And around the same time Firebug launched, WebKit introduced its own WebKit Inspector, but it was initially limited to inspecting HTML and CSS and lacked the JavaScript features found in Firebug.

Firebug changed the web development world in several ways. On a practical level it made it much easier to write and debug JavaScript, as well as inspect the DOM and even see which styles were applied to a particular HTML node. Google took these ideas and ran with them when it introduced its Chrome browser with its developer-friendly set of tools. Today there are no desktop web browsers without developer tools. Yes, even IE 10+ has some great built-in tools for developers.

But Firebug, WebKit Inspector and the Chrome Developer Tools represented a much larger shift in how the web is built - developer tools in the browser moved the task of building the webpages from separate standalone IDEs like Dreamweaver from Macromedia/Adobe or (shudder) Microsoft FrontPage to the actual web browser. Dreamweaver still exists, but it has largely fallen by the wayside. These days you'd be hard-pressed to find an article or tutorial on web development that even mentions it.

Today you can build entire web applications without ever leaving the web browser.

The developer package in the latest versions of Chrome, Opera and Firefox are comprised of several dozen tools covering everything from DOM inspectors to network waterfalls to timeline to integrated page speed auditors. There are coding panels, JavaScript consoles, memory profilers, integrated text editors (including editors with Vim and Emacs keybindings support) - even screenshot and color eyedroppers in the latest version of Firefox.

In cases where the packaged tools aren't enough there are plenty of browser add-ons to extend their range. Want a basic shell in your browser? Just grab the Devtools Terminal add-on for Chrome. How about a visual CSS editor, an accessibility auditor or even an entire FTP/SFTP client?

There's an embarrassment of riches waiting for web developers in today's browsers. But, while today's browser-based developer tools are fantastically powerful and continue to arrive at an almost overwhelming pace, developing websites directly in the browser is still harder than it should be in many ways.

Oy, again with the server

Even seemingly simple things like using the editor of your choice isn't entirely possible. For example, while you can get some of the power of Vim or Emacs in your browser, you certainly can't get all of it. Mozilla has demonstrated a proof of concept that would allow an outside text editor to control Firefox via some Python scripts, but that project has never shipped and its current status is unclear.

Some developers argue it would have been better to put the browser's runtime in your text editor rather than the other way around, but at this point that seems unlikely to happen.

There's also still a huge disconnect between the tools used to write and test client-side code (like JavaScript and CSS) and the server side tools that actually send that code to the browser. That disconnect is part of why modern web development is such a morass of third-party tools.

Consider, for example, the seemingly simple process of writing a bit of JavaScript for a WordPress theme. While you can write, edit and debug your JavaScript in the Chrome or Firefox developer tools, you still need a local server to render the WordPress page your JavaScript is attempting to manipulate in the first place.

With any luck, though, this disconnect will be one of the next big areas browser makers tackle. Just imagine a developer tools panel that can act as a simple server, just point it to a folder and it handles the rest.

Tools like Node.js (itself extracted from Chrome's JavaScript engine) could offer a way to embed simple servers, connect the browser to your build tools, preprocessors and even your favorite editor.

We can hope. ®