A small nitpick: the article lists the "IE Developer Toolbar" for IE6 first, and suggests that everybody else's development tools followed that model. In fact, the earliest reference I can find to the IE Developer Toolbar suggests[1] that it was released in early 2007, while the Firebug version history[2] shows Firebug v0.2 released in January 2006, so it's about a year older than IE's developer tools.
Even if Firebug itself is no longer head-and-shoulders better than other tools, the fact that the basic model was copied and polished by Microsoft, Apple, Opera and later Mozilla themselves shows that Joe Hewitt had a pretty great idea back in early 2006.
The Mozilla DOM inspector is even older, it was even bundled in the Firefox installer in 2003. If the IE toolbar DOM inspector which was the reason some devs used IE 6 like the article suggests, I would bet that they had never even tried Firefox.
And once again the top comment doesn't do anything to continue the thoughtful discussion that began in the article, instead providing a pedantic correction.
Yes, before Firebug, we were using MS Script Debugger/Script Editor in IE. It wasn't great, but it was more reliable for script debugging than Firebug for a long time.
This is an interesting discussion. I'm deep into a project now (as the sole developer) where I was surprised to learn that the frontend js is about 30% bigger than the backend (python).
In ipython I use autoreload (thanks to a tip on HN) so that the code in the objects in memory is kept in sync with my editor. My workflow is: load up a bunch of objects I'm working on, try to get the expected output, fail, change code in my editor again, check the the output, repeat. Within ipython you can even '%ed obj.broken_function' to edit it directly in vim. There's no doubt that the auto reload discovery improved my efficiency. Aside from the time it saves, I'm able to think of my running code and on disk code as the same thing. Don't underestimate how powerful that is.
But as I said, my code is now mostly frontend code. After over 15 years in web development the reload cycle has become second nature to me. It's silly though. I have a lot of state to maintain in the js and every reload is expensive. In my specific case I could be looking at 2 minutes to even load the objects from the web server.
I'm going to have a look at the chrome options to see what's available in terms of hot code swapping. I disagree that it's important for all browsers to support it. Even just finding a good solution in the browser I do most development in (chrome, presently) would be a major win.
Many of the workflow elements discussed in the article apply more to designers than developers; for example: live reload which is very useful in the context of rapidly iterating on design changes but quickly loses appeal when working on a rich-client web application using a JavaScript framework where you have long-lived state present in the page.
Much of the way the web is being built is evolving from static pages and presentation to full-blown applications running completely in the browser which is why there is such a shift to providing tools for visualizing complex pieces of browser operations like rendering, compositing [1] and painting [2].
I don't think there's any fundamental problems with the tools being developed, the reason workflows are broken is because many web developers aren't being empowered to learn web development fundamentals. I can't imagine starting out as a web developer in 2013 and trying to jump in with all of these abstractions, tools and workflow items to try and understand; it'd be like trying to jump in as a newcomer to Rails at the latest version without all the context of the changes that lead to design decisions that currently make up the latest iteration of "The Rails Way". [3]
I think tooling is in a pretty good place now; browser vendors need to start educating web developers about how to craft workflows and use the tools out there. My goal has been to try and educate more web developers about browser and web fundamentals [4] along with workflow fundamentals like automating tasks using Grunt. [5]
I actually thought that was where this article was going, and was very surprised when it wasn't mentioned.
I will say though (as a lighttable backer with the fancy-schmancy t-shirt to prove it) that the current builds of light table are... incomplete. The idea of lighttable is very exciting, but I haven't really found the current builds to be much use. They are too similar to existing editors / workflows, and as it's beta you're sacrificing stability for not a whole lot of gain.
Light Table is very interesting (I've used it for some Clojure stuff), but it's competing with emacs. It's gonna be very hard to beat emacs. The legacy of thousands of lines of very useful code & unbelievable extensibility is a big one to overcome. I don't mind saying that I foresee emacs getting a lighttable-mode for dynamic languages before Light Table beats emacs. But I usually have a LightTable install on my computers; it's that promising of a project. :-)
The workflow might need polishing, but tools like SublimeInspector are not the answer. They are miles behind the Chrome Inspector. Try it if you're not convinced.
The Chrome team has shown that they are very interested in moving the Inspector forward and have succeeded in integrating local files access via the editor, SASS support, Source Maps support, and a lot more. It is to the point where it would not be crazy to consider building a site entirely within the inspector. While the editor is not as good as others, you do gain simplicity and the ability to patch running code. The workflow is getting better.
Writing a great inspector is the hard part. Comparatively, writing an editor should not be as difficult. Chrome built the inspector first and is circling around.
The only integration I would really care to see (perhaps via ST2 Package Control) is the ability to directly pipe into the Inspector and patch running code. For large projects, especially in development mode, it can be a drag to ajax in >200 source files (even from localhost) and refresh every time you make a change.
I'm interested in understanding why you are "ajax[ing] in > 200 source files" in development mode? This provides a pretty poor developer experience IMHO; I've found a much better workflow in setting up a single concatenated unminified bundle for development using grunt-concat-sourcemaps [1] to provide source mappings that Chrome Developer Tools can browse.
This gives you the snappy page loads you'd expect with a single script element in the page, and still allows you to debug in your separate source files due to the sourcemappings. The only difference between javascript in development and production should be the minification step.
'We have a lot of stateful frontend code that's hard to debug and test.'
'Maybe you should strive for less stateful frontend code?'
'Nonsense! We should completely reingeneer our workflows and toolchains to accommodate whatever we're doing right now, because everything else is stupid and outdated.'
I feel like this sentiment has been bubbling under the surface of my thought process every time I open up my editor. I've never taken the time to scrutinize that feeling though, too busy stressing over the details of whatever I'm making.
Perhaps only tangentially related, but our workflows are significantly related to the technologies we use, right? Ian Hickson in an interview [0]
"The Web technology stack is a complete mess. The problem is: what would you replace it with?"
While these comments are indeed useful, they are an aside to the article. I wonder if there is a way to make it so that the link will redirect to the google cache version if the server is down automatically.
With weinre you start a node.js debug server and add one script tag in your html. Then you start the debug client in a webkit compatible browser and finally the browser with the page you are debugging (it can be anything: mobile, remote or not).
weinre strongest points are:
- "weinre supports remote interaction, so you can run the debugger user interface on one machine and can debug a web page running on another machine. For instance, debug a web page displayed on your phone from your laptop."
- "weinre does not make use of any native code in the browser, it's all plain old boring JavaScript."
- "Because weinre doesn't use native code, the debug target code will run on browsers without specialized debug support."
Also try Live Reload[2], mentioned in the article, for a nicer editor+your_tool+browser integration.
- "LiveReload monitors changes in the file system. As soon as you save a file, it is preprocessed as needed (SASS, LESS, Stylus, Coffescript and others), and the browser is refreshed." (You don't hit reload, it uses a browser extension or a script tag)
- "LiveReload can invoke a Terminal command after processing changes. Run a Rake/Cake task, a Shell script or anything else you need."
Most web development workflows emerged in an era of monolithic, server-side driven application development. Lots of server side code (as well as navigation logic and session state), relatively small amount of browser side code. In recent web app development, client side now has a larger proportion of the code and complexity. Developers tend to make incremental changes to their workflow rather than "starting from scratch" seem to miss the shift that has taken place.
One of the best examples of an efficient workflow (at least in theory) that I have seen is the Play framework, along with a browser plugin that causes the browser to refresh every time source code is saved (http://www.jamesward.com/2013/05/15/auto-refresh-for-play-fr...).
Not to take anything away from this but that's not really achieving the desired effect. There's still a browser refresh happening so you lose your state every time. You're still stuck in the same cycle. In an ideal world you would be able to change code in your editor and have those changes reflected within the objects already loaded in your browser.
It looks, like "web" is slowly moving towards Smalltalk's concepts (everything including dev-tools is dynamic and changeable live in runtime). I wonder how many years it will take us to get there
People are trying to "fix" the web, when it should be replaced or redesigned. Thus problem is human, not technical. Whom should decide what replaces all the TLA that is required for the "modern" web? Too much time and money is invested in browsers, servers, languages, frameworks, training, tools etc...
Not that's all bad. A lot of technology that wouldn't have been developed, has been. It's changed a lot since I started building sites in '94. But I still can build nicer apps for the desktop, with better interfaces, better performance using a single programming language faster than I can develop "rough" equivalent web application.
We use a static node server with live reload that monitors the source tree for modifications. It compiles and hot-swaps stylus files the moment you hit save (the ability to do that obviously depends on how we implemented style appliers for our view classes). Localization sources, and templates are also compiled on modification, and the browser is told to refresh once it detects a modification on javascript. This means any change I make in whatever text editor I chose, is immediately reflected in the browser. And since we built our front-end app with verbose and stateful routes, I never am taken away from the current view I am working on.
We plan on releasing our dev toolset open source soon, but we want to retool require and handlebars to be able to also be hot-swapped without reloading the browser.
I guess I am trying to say you are the master of your workflow, if it sucks, make it better.
Indeed. My first thought was "speak for yourself". I wanted to read the article before writing my justification for my opinion, but I suppose this works.
The workflow cycle suggested in the article is broken, but the normal web development workflow is not. I would definitely not restart my editor and browser after every edit!
The workflow is actually just like with any other programming environment. You make changes to the code with your editor and then you reload the page or restart the application. If you really need to, you can use a debugger to see what's going on.
Fancy integration between the editor and the debugger is nice, but it hardly breaks the workflow.
Indeed, his workflow is broken. For me the problem he describes doesn't even exist as tweaking pixels is such a minor part of my "web development" work. The vast majority is backend stuff or simple HTML that doesn't need debugging tools.
That being said, there is certainly room for improvement when problems happen.
> When using the browser as code-editor, we are entering a world of new problems. The browser is designed to abstract away the local file system, and is based upon a read-only/execute-only model. In order to “fix” this we have introduced a new type of browser extensions, that’s trying to fix this.
It isn't really a read-only environment! It can't read anything! All the browser can do is GET and POST things...
...so maybe the problem with web development is that it is all based on files?
I like my workflow with Arch/Xmonad/vim/Chrome. More broken than workflow is javascript, rendering engines, and the DOM. We shouldn't need as many tools as we do, but unfortunately we simply cannot trust our "correct" code, markup and style sheets to result in the expected. As long as these things are broken, workflow will be too.
A remote protocol is super-handy. Anyone who has used CL w/ SLIME and a compatible editor can attest to this. There's even a little project called slime-proxy[1] which proxies the javascript compiled from parenscript in a REPL to a connected browser via websockets. It is a much more elegant way to develop applications for the browser than the reloading hacks that are popular today.
I like the idea of changing the dev workflow a lot.
What I don't understand though is what makes the Webkit Developer Tools better than Firebug.
I don't want to defend Firebug, but in my experience the Developer Tools are a pain to use in comparison to Firebug. (e.g. autocompletion of css properties and property values only works with tab and not also with return, it takes too many clicks to see the metrics,....).
What's the features that make the Developer Tools better in your experience?
[+] [-] thristian|12 years ago|reply
Even if Firebug itself is no longer head-and-shoulders better than other tools, the fact that the basic model was copied and polished by Microsoft, Apple, Opera and later Mozilla themselves shows that Joe Hewitt had a pretty great idea back in early 2006.
[1]: http://blogs.msdn.com/b/ie/archive/2007/01/09/ie-developer-t...
[2]: https://addons.mozilla.org/en-US/firefox/addon/firebug/versi...
[+] [-] mattmanser|12 years ago|reply
Here's an article about the beta 1 refresh from Nov 2005, so it was out even earlier than that.
http://blogs.msdn.com/b/ie/archive/2005/11/01/487833.aspx
Your google-fu needs a lot of work as even my first search showed a lot of articles in 2006 and 2007 talking about the IE dev toolbar, e.g.:
http://betanews.com/2007/05/10/microsoft-releases-ie-develop...
EDIT: Interestingly reading through some of the comments on the first post, it seems people claim the IE dev toolbar was inspired by http://chrispederick.com/work/web-developer/ and the initial release date for the IE Dev toolbar was Sept 2005 (see http://c82.net/posts.php?id=23)
[+] [-] wmt|12 years ago|reply
http://kb.mozillazine.org/DOM_Inspector
[+] [-] ritchiea|12 years ago|reply
[+] [-] Fuxy|12 years ago|reply
Not to mention i was using Firebug before IE had any development tools so it saddens me that Microsoft gets credit for it.
[+] [-] kybernetikos|12 years ago|reply
[+] [-] aidos|12 years ago|reply
In ipython I use autoreload (thanks to a tip on HN) so that the code in the objects in memory is kept in sync with my editor. My workflow is: load up a bunch of objects I'm working on, try to get the expected output, fail, change code in my editor again, check the the output, repeat. Within ipython you can even '%ed obj.broken_function' to edit it directly in vim. There's no doubt that the auto reload discovery improved my efficiency. Aside from the time it saves, I'm able to think of my running code and on disk code as the same thing. Don't underestimate how powerful that is.
But as I said, my code is now mostly frontend code. After over 15 years in web development the reload cycle has become second nature to me. It's silly though. I have a lot of state to maintain in the js and every reload is expensive. In my specific case I could be looking at 2 minutes to even load the objects from the web server.
I'm going to have a look at the chrome options to see what's available in terms of hot code swapping. I disagree that it's important for all browsers to support it. Even just finding a good solution in the browser I do most development in (chrome, presently) would be a major win.
[+] [-] chii|12 years ago|reply
[+] [-] davemo|12 years ago|reply
Much of the way the web is being built is evolving from static pages and presentation to full-blown applications running completely in the browser which is why there is such a shift to providing tools for visualizing complex pieces of browser operations like rendering, compositing [1] and painting [2].
I don't think there's any fundamental problems with the tools being developed, the reason workflows are broken is because many web developers aren't being empowered to learn web development fundamentals. I can't imagine starting out as a web developer in 2013 and trying to jump in with all of these abstractions, tools and workflow items to try and understand; it'd be like trying to jump in as a newcomer to Rails at the latest version without all the context of the changes that lead to design decisions that currently make up the latest iteration of "The Rails Way". [3]
I think tooling is in a pretty good place now; browser vendors need to start educating web developers about how to craft workflows and use the tools out there. My goal has been to try and educate more web developers about browser and web fundamentals [4] along with workflow fundamentals like automating tasks using Grunt. [5]
[1] - http://www.youtube.com/watch?v=x6qe_kVaBpg
[2] - http://www.youtube.com/watch?v=Ea41RdQ1oFQ
[3] - http://words.steveklabnik.com/rails-has-two-default-stacks
[4] - http://www.youtube.com/watch?v=Lsg84NtJbmI
[5] - http://www.youtube.com/watch?v=fSAgFxjFSqY
[+] [-] bradleysmith|12 years ago|reply
Thanks for the fundamentals video & grunt intro, both were helpful to me.
[+] [-] ricardobeat|12 years ago|reply
[+] [-] SCdF|12 years ago|reply
I will say though (as a lighttable backer with the fancy-schmancy t-shirt to prove it) that the current builds of light table are... incomplete. The idea of lighttable is very exciting, but I haven't really found the current builds to be much use. They are too similar to existing editors / workflows, and as it's beta you're sacrificing stability for not a whole lot of gain.
[+] [-] pnathan|12 years ago|reply
[+] [-] loupeabody|12 years ago|reply
[+] [-] ssafejava|12 years ago|reply
The Chrome team has shown that they are very interested in moving the Inspector forward and have succeeded in integrating local files access via the editor, SASS support, Source Maps support, and a lot more. It is to the point where it would not be crazy to consider building a site entirely within the inspector. While the editor is not as good as others, you do gain simplicity and the ability to patch running code. The workflow is getting better.
Writing a great inspector is the hard part. Comparatively, writing an editor should not be as difficult. Chrome built the inspector first and is circling around.
The only integration I would really care to see (perhaps via ST2 Package Control) is the ability to directly pipe into the Inspector and patch running code. For large projects, especially in development mode, it can be a drag to ajax in >200 source files (even from localhost) and refresh every time you make a change.
[+] [-] davemo|12 years ago|reply
This gives you the snappy page loads you'd expect with a single script element in the page, and still allows you to debug in your separate source files due to the sourcemappings. The only difference between javascript in development and production should be the minification step.
[1] https://github.com/kozy4324/grunt-concat-sourcemap
[+] [-] Bogdanp|12 years ago|reply
[1]: https://github.com/Bogdanp/browser-connect.vim
[+] [-] flaie|12 years ago|reply
Would it be possible for you to add the source code of the play application (server) to your github ?
Thank you for your plugin :)
[+] [-] VMG|12 years ago|reply
[+] [-] romaniv|12 years ago|reply
'We have a lot of stateful frontend code that's hard to debug and test.'
'Maybe you should strive for less stateful frontend code?'
'Nonsense! We should completely reingeneer our workflows and toolchains to accommodate whatever we're doing right now, because everything else is stupid and outdated.'
[+] [-] gkop|12 years ago|reply
[+] [-] loupeabody|12 years ago|reply
Perhaps only tangentially related, but our workflows are significantly related to the technologies we use, right? Ian Hickson in an interview [0]
"The Web technology stack is a complete mess. The problem is: what would you replace it with?"
[0]http://html5doctor.com/interview-with-ian-hickson-html-edito...
[+] [-] codelion|12 years ago|reply
[+] [-] chacham15|12 years ago|reply
[+] [-] falava|12 years ago|reply
"The remote debugging protocols are incompatible with each other, and each has a different features."
[1]http://people.apache.org/~pmuellr/weinre/docs/latest/
With weinre you start a node.js debug server and add one script tag in your html. Then you start the debug client in a webkit compatible browser and finally the browser with the page you are debugging (it can be anything: mobile, remote or not).
weinre strongest points are:
- "weinre supports remote interaction, so you can run the debugger user interface on one machine and can debug a web page running on another machine. For instance, debug a web page displayed on your phone from your laptop."
- "weinre does not make use of any native code in the browser, it's all plain old boring JavaScript."
- "Because weinre doesn't use native code, the debug target code will run on browsers without specialized debug support."
Also try Live Reload[2], mentioned in the article, for a nicer editor+your_tool+browser integration.
[2]http://livereload.com/
- "LiveReload monitors changes in the file system. As soon as you save a file, it is preprocessed as needed (SASS, LESS, Stylus, Coffescript and others), and the browser is refreshed." (You don't hit reload, it uses a browser extension or a script tag)
- "LiveReload can invoke a Terminal command after processing changes. Run a Rake/Cake task, a Shell script or anything else you need."
[+] [-] EzGraphs|12 years ago|reply
One of the best examples of an efficient workflow (at least in theory) that I have seen is the Play framework, along with a browser plugin that causes the browser to refresh every time source code is saved (http://www.jamesward.com/2013/05/15/auto-refresh-for-play-fr...).
[+] [-] aidos|12 years ago|reply
[+] [-] indeyets|12 years ago|reply
[+] [-] xradionut|12 years ago|reply
People are trying to "fix" the web, when it should be replaced or redesigned. Thus problem is human, not technical. Whom should decide what replaces all the TLA that is required for the "modern" web? Too much time and money is invested in browsers, servers, languages, frameworks, training, tools etc...
Not that's all bad. A lot of technology that wouldn't have been developed, has been. It's changed a lot since I started building sites in '94. But I still can build nicer apps for the desktop, with better interfaces, better performance using a single programming language faster than I can develop "rough" equivalent web application.
[+] [-] octatone2|12 years ago|reply
We use a static node server with live reload that monitors the source tree for modifications. It compiles and hot-swaps stylus files the moment you hit save (the ability to do that obviously depends on how we implemented style appliers for our view classes). Localization sources, and templates are also compiled on modification, and the browser is told to refresh once it detects a modification on javascript. This means any change I make in whatever text editor I chose, is immediately reflected in the browser. And since we built our front-end app with verbose and stateful routes, I never am taken away from the current view I am working on.
We plan on releasing our dev toolset open source soon, but we want to retool require and handlebars to be able to also be hot-swapped without reloading the browser.
I guess I am trying to say you are the master of your workflow, if it sucks, make it better.
[+] [-] kevinburke|12 years ago|reply
[+] [-] contingencies|12 years ago|reply
[+] [-] benatkin|12 years ago|reply
[+] [-] auchenberg|12 years ago|reply
[+] [-] jelled|12 years ago|reply
[+] [-] wmt|12 years ago|reply
The workflow is actually just like with any other programming environment. You make changes to the code with your editor and then you reload the page or restart the application. If you really need to, you can use a debugger to see what's going on.
Fancy integration between the editor and the debugger is nice, but it hardly breaks the workflow.
[+] [-] nkuttler|12 years ago|reply
That being said, there is certainly room for improvement when problems happen.
[+] [-] williamcotton|12 years ago|reply
It isn't really a read-only environment! It can't read anything! All the browser can do is GET and POST things...
...so maybe the problem with web development is that it is all based on files?
[+] [-] BasDirks|12 years ago|reply
[+] [-] agentultra|12 years ago|reply
[1] https://github.com/3b/slime-proxy
[+] [-] sirwitti|12 years ago|reply
I don't want to defend Firebug, but in my experience the Developer Tools are a pain to use in comparison to Firebug. (e.g. autocompletion of css properties and property values only works with tab and not also with return, it takes too many clicks to see the metrics,....).
What's the features that make the Developer Tools better in your experience?
[+] [-] williamcotton|12 years ago|reply
Check this out: https://developers.google.com/chrome-developer-tools/docs/ti...