Live data from Hacker News

Our web development workflow is completely broken

blog.kenneth.io

31–40 of 121 posts

Re: Our web development workflow is completely broken

#32
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]

[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

Re: Our web development workflow is completely broken

#33
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…

I just started using Browserify with browserify-middleware and coffeeify, and it's fantastic. No build tool needed (even in production if you setup caching)

Re: Our web development workflow is completely broken

#34
This is one of the problems that TDD tries to solve.

To make changes to a small piece of code, you don't want to have to go through a huge iteration of running up your server, going to your browser, moving around the app to get into the required state and then trying out the bit of functionality. No, you just write a test for that bit of code and run it. No browser needed.

The cycle he describes is what you do at the very end. Once.

Re: Our web development workflow is completely broken

#35
post #28

Earlier quoted context omitted.

If it weren't for pedants, we wouldn't have computers.

Yes, because the introduction of the computer was a minor change to the world that only a pedant would have bothered with?

Good point, it wasn't a minor change. I meant to specify working computers.

Re: Our web development workflow is completely broken

#36
I whipped together a quick and dirty tool to auto-refresh a web page when specified files are altered in the file-system: https://github.com/lukifer/Freshrr

This may not fully solve the problem, but it does eliminate a couple superfluous workflow steps. Chrome's inspector even tends to remember DOM context (not sure about Firebug or Safari's inspector).

Re: Our web development workflow is completely broken

#37
post #26

On one hand, the whole web stack is completely broken and insane. On the other hand, if you use the right development methodologies such as unit testing, MVC, MVP, MVVM, and/or frameworks that translate statically typed or functional code to JS, the write-build-run-debug cycle is not an issue, because in general it only becomes an issue with a wrong approach to programming. This is totally the same as in non-web-prog…

Yeah, I also think there should be a more fundamental discussion about where the web is heading. Instead of fixing the tools perhaps one should think about a new foundation for everything. Not sure HTML etc. is it.

Re: Our web development workflow is completely broken

#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.

Re: Our web development workflow is completely broken

#39
post #13

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…

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?
Post reply on HN