Live data from Hacker News

Our web development workflow is completely broken

blog.kenneth.io

51–60 of 121 posts

Re: Our web development workflow is completely broken

#51
post #38

Why are we doing this backwards compared to everyone else? Integrating debugging tools into the runtime (browser) is great, but everyone else tends to integrate them into the IDE. Wouldn't that make more sense?

It's nice to be able to deal with stuff in the environment in which it will be used.

Sure, and that's why when you are in eclipse and you're debugging java, you are connected to a real jvm. I don't see any reason why you couldn't be connected to a real browser from inside an IDE. In an ideal world, all browsers would export (or have a plugin that did it for them) a standardised debugging interface.

Re: Our web development workflow is completely broken

#52
I wonder how much of this applies not only to front-end javascript style stuff but also the backend server rich code. You also debug with a navigate to page, find the right code in editor, change, reload cycle. Granted, you miss out the "change values in developer tools in the browser", but it isn't so far removed.

Re: Our web development workflow is completely broken

#53

Earlier quoted context omitted.

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.

Before Firebug, there was Venkman[0] which was definitely shite but worked if you had enough courage to understand its byzantine behavior. It provided a profiler on top of the JS debugger. And IE development could use Visual Studio (and later Visual Studio Express web edition) for a slightly better experience than the MS Script Debugger, although the core issues such as not being able to see let alone debug toplevel…

I tried Venkman but found it so terrible I would do most of my script debugging in IE.

Re: Our web development workflow is completely broken

#54

LightTable has some pretty interesting features in this direction: http://www.chris-granger.com/2013/04/28/light-table-040/

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.

Re: Our web development workflow is completely broken

#55
post #22

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…

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 sing…

With requirejs, I run into the `mismatched anonymous define() module` issue when using concat-sourcemap. The "correct" way around it is to use r.js, but it takes about 2.5s to compile that way, which happens to be more than it takes for ajax to work its magic locally.

Running SPDY locally helps a lot. Even with all those files I hit DOMReady at about 2.7s with no concatenation.

Re: Our web development workflow is completely broken

#57

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 Firebu…

I was about to point that out myself giving credit where credit is due is important and that is a considerable mistake in my eyes.

Not to mention i was using Firebug before IE had any development tools so it saddens me that Microsoft gets credit for it.

Re: Our web development workflow is completely broken

#59

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 Firebu…

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.

It's not the most important comment on the subject, but it is right that the firebug developer get credit.

Re: Our web development workflow is completely broken

#60
post #39

Earlier quoted context omitted.

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.

Just because he's doing different work than you, his workflow is broken?

He wrote it himself, didn't he? You're totally reading that into what I wrote...

Some part of "web development" could use improvements.

Post reply on HN