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

81–90 of 121 posts

Re: Our web development workflow is completely broken

#81

Post by aptwebapps »

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.

There's nothing wrong with the comment in and of its self, in my opinion. In fact, I appreciate it. But it's too bad that relevance to the original article seems to have so little correlation with votes.

Re: Our web development workflow is completely broken

#82

Post by masklinn »

kybernetikos wrote: post #53
masklinn wrote: post #45

Earlier quoted context omitted.

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.

It admittedly had a learning curve roughly on-part with Eclipse over POTS with a drunk monkey at the other end of the call. I was rather happy when Firebug came into my world.

Re: Our web development workflow is completely broken

#83

Post by swannodette »

aidos wrote: post #78
chii wrote: post #73

Earlier quoted context omitted.

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

I think chii was referring to a much more sophisticated REPL experience which doesn't require blowing away application state. This is possible in truly live environments like Smalltalk (checkout Squeak) or a competent Lisp environment. You can incrementally update your program from your editor and keep going all without reloading. This is how ClojureScript developers interact via the browser REPL for example.

Re: Our web development workflow is completely broken

#84

Post by PommeDeTerre »

j45 wrote: post #24

This was all much, much, harder 10-15 years ago. Of course, this may only make sense in 10-15 years when there's even better tools than today. Regardless, there will always be a desire for it to be easier, and it will always be work.

But the JavaScript development tools today really aren't that much different, never mind better, than what we had 10 or 15 or even 20 years ago when using C, or C++, or Java, or even Turbo Pascal and Delphi.

The basic principles and functionality has remain essentially unchanged the entire time. We're still mainly setting breakpoints, stepping through code, inspecting variables, and so forth.

Those of us who have been in industry a long time have seen much greater gains from the use of strong, static typing and unit testing, for instance. The best way to use a debugger is to not use it at all, because many of the bugs have been prevented outright by the nature of the language used, or at worst caught immediately by the compiler or automated tests.

Re: Our web development workflow is completely broken

#85

Post by davemo »

ssafejava wrote: post #55
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…

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.

I wouldn't choose to use requirejs on a project where I was making choices about the architecture for reasons mentioned here [1], but the current project I'm on was setup similarly and loads over 350 .js and .tpl files via AJAX in development mode pushing the DOMReady to a staggering 7.5s. (This is inside of Rails 3.2 using the requirejs gem).

Every time I've encountered requirejs in an application this has been representative of my experience with the tool and the pain of having to wait that long every time I reload a page simply doesn't seem worth it to me. There's also somewhat of a mismatch between async loading assets in development and sync loading them in production which I've seen responsible for bugs that show up in one environment but not the other, and/or vice versa.

A couple of questions for you: do you think the r.js optimizer taking 2.5s to compile is related to the complexity of the dependency tree in your application or just the number of files being loaded? Also, considering the previously mentioned mismatch between dev/prod and async loading, do you think it is appropriate to use something like SPDY to obviate the pain of a lengthy DOMReady event in development?

[1] - http://searls.testdouble.com/posts/2013-06-16-unrequired-lov...

Re: Our web development workflow is completely broken

#86

Post by davemo »

jnbiche wrote: post #79
tlrobinson wrote: post #33

Earlier quoted context omitted.

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, wh…

Between browserify and requirejs I've definitely had a more positive experience with the former but my experience is that both seem to be subject to scaling problems with even a trivial number of dependencies in play; I wish there was a really good sample project setup that would allow accurate comparisons between the tools at the scale they are frequently used at, but for now I choose to use simple concatenation and a simple namespacing tool [1] to avoid lengthy watch-time issues during development.

grunt-contrib-watch is a pretty vital part of my workflow, but I don't use the livereload options because I can't afford to lose that state in the browser.

[1] - https://github.com/searls/extend.js

Re: Our web development workflow is completely broken

#87

Post by xradionut »

indeyets wrote: post #23

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

I give it two decades.

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.

Re: Our web development workflow is completely broken

#89

Post by balac »

counterpointer wrote: post #76
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.

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.

You might find the Hacker News Collapse extension useful: https://chrome.google.com/webstore/detail/hacker-news-collap...

Re: Our web development workflow is completely broken

#90

Post by jasonkarns »

tuxcanfly wrote: post #47
weavie wrote: post #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…

From my experience, frontend tests break easily in unexpected ways e.g. div moved by an inch? Error - element-not-visible!

Depends on your definition of frontend tests. TDD alleviates these workflow problems for javascript (the actual code of the application). But using automated tests for the UI layout is gonna be a bad time. As @davemo mentioned, this post seems primarily directed at a designer's workflow with CSS and less about javascript development.
Post reply on HN