Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our web development workflow is completely broken

blog.kenneth.io

Post reply on HN
Print view View original

71–80 of 121 posts

Re: Our web development workflow is completely broken

#71

Post by twelvechairs »

SCdF wrote: post #54
ricardobeat wrote: post #2

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…

I agree. would add that a comprehensive solution is needed - not just one for particular types of development.

I was working in background on my own system before light table appeared. am back on it now in my spare time since light table is aiming away from my requirements. every time I see an article like this i think I should have worked harder to get it working by now

Re: Our web development workflow is completely broken

#72

Post by lmm »

ritchiea wrote: post #16
thristian wrote: post #4

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.

And once again the top reply to the top comment has even less value, sending us off into pointless meta-discussion.

Re: Our web development workflow is completely broken

#73

Post by chii »

aidos wrote: post #49

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…

this autoreload/live edit is sounding more and more like a REPL...

Re: Our web development workflow is completely broken

#74

Post by EzGraphs »

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

Re: Our web development workflow is completely broken

#76

Post by counterpointer »

ritchiea wrote: post #16
thristian wrote: post #4

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.

This would be much less of a problem if we could collapse comment trees like on Reddit. It would be just easy to minimize and ignore. I think someone made an extension for that.

Re: Our web development workflow is completely broken

#77

Post by brown9-2 »

chii wrote: post #73
aidos wrote: post #49

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…

this autoreload/live edit is sounding more and more like a REPL...

Ipython is a REPL.

Re: Our web development workflow is completely broken

#78

Post by aidos »

chii wrote: post #73
aidos wrote: post #49

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…

this autoreload/live edit is sounding more and more like a REPL...

Hmm. Evidently I didn't explain that very well. In ipython you're working in a REPL. Say you have a good many classes loaded up with data but some function deep inside one of them isn't producing the correct output. You can debug as you normally would inside the REPL. Use a debugger, deconstruct the function etc. When you get to the end you now have a fix for your function. Make that change in your file and, thanks to auto reload all of the objects in memory are immediately running the fixed function. You can then carry on working with the objects as though the bug was never there.

Depending on your scenario this can be a major win. On my project it's not uncommon for it to take 10 minutes to load and process that data from disk to get it into objects in memory. For me I can do that once and then carry on working with my data an code all in unison.

Whatever works for you. I'm pleased with my current environment on the server-side. It works very well for me.

Re: Our web development workflow is completely broken

#79

Post by jnbiche »

tlrobinson wrote: post #33
davemo wrote: post #22

Earlier quoted context omitted.

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)

Browserify is wonderful. I had trouble with browserify-middleware on nodejs, because it took so long to load -- several seconds, compared with under 1 second using the browserify "binary" tool. So I paired the browserify binary with livereload and grunt-contrib-watch, and it's now a very quick process every time I change the code.

However, it doesn't at all address the issue of losing JavaScript state upon reload, which is one of the main problems this post is emphasizing.

Re: Our web development workflow is completely broken

#80

Post by RyanMcGreal »

lmm wrote: post #72
ritchiea wrote: post #16

Earlier quoted context omitted.

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.

And once again the top reply to the top comment has even less value, sending us off into pointless meta-discussion.

Pike: That's a technicality.

Spock: I am Vulcan, sir. We embrace technicalities.

Post reply on HN