1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
In the first two parts of this series I looked at the massive changes in web development that have occurred over the last twenty years.
Today's web is one where developers <a href="http://www.theregister.co.uk/2014/07/21/programming_the_web_25/">have crowd-funded new features</a> into popular web browsers and now, thanks to coming tools like the Web Components stack, the future of the web looks to <a href="">involve web developers</a> as much as traditional web innovators like browser makers and standards bodies.
That's all well and good, but if you're a web developer slogging it out in the development trenches most of this stuff probably hasn't had a dramatic impact on your day-to-day workflow just yet. Which brings us to perhaps the most revolutionary aspect of all the changes in web development over the last two decades -- 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 IE 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 that 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 webapps 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 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. Firebug, initially a browser add-on for Firefox, 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 Internet Explorer 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 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 tools in 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 <a href="http://longhandpixels.net/blog/2014/02/live-editing-sass-firefox-vim-keybindings">editors with Vim and Emacs keybindings support</a>) -- even screenshot and color eyedroppers in the latest version of Firefox.
In cases where the existing tools aren't enough there are plenty of browser add-ons to extend the developer tools. Want a basic shell in your browser? Just grab the <a href="https://chrome.google.com/webstore/detail/devtools-terminal/leakmhneaibbdapdoienlkifomjceknl">Devtools Terminal add-on</a> for Chrome. How about a <a href="https://chrome.google.com/webstore/detail/code-cola/lomkpheldlbkkfiifcbfifipaofnmnkn">visual CSS editor</a>, an <a href="https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb">accessibility auditor</a> or even an entire <a href="https://addons.mozilla.org/en-us/firefox/addon/fireftp/">FTP/SFTP client</a>?
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.
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 <a href="http://paulrouget.com/e/devtoolsnext/">control Firefox via some Python scripts</a>, but that project has never shipped and its current status is unclear.
Some developers argue that 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're still going to need a local server setup to render the WordPress page that your JavaScript is attempting to manipulate in the first place.
With any luck this disconnect will be one of the next big areas browser makers tackle -- 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.
|
