Live data from Hacker News

Our web development workflow is completely broken

blog.kenneth.io

111–120 of 121 posts

Re: Our web development workflow is completely broken

#111
post #97

Earlier quoted context omitted.

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

> aiming away from my requirements Out of curiosity, what are your requirements? It's hard for me to imagine that LT is really aiming away from anyone :) It's a platform for building whatever workflow you could want, integrated with any system/language/service you can find. That particular aspect of it hasn't been released quite yet, but it will be the major focus of the beta.

What about document oriented editing? Forms and word processor kind of functionality?

I'm researching browser development frameworks and languages to develop an XML editor. Editing should work more like Google Docs than CodeMirror, and with rudimentary form support (think key-value metadata, not complex forms).

So far I have settled on using contenteditable, but structural editing of XML in document oriented fashion is still an open question. One user action can result in many XML tree changes, like pushing enter twice inside a paragraph should split it in two (and thus close and create any number of tags). Also, there is no schema to describe XML document's editing workflow. Your post on IDE as a value gave me insight for a possible implementation.

Also, big thank you for LT. I'm enjoying using it immensely.

Re: Our web development workflow is completely broken

#112

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…

No, you're wrong. You weren't around obviously, so you probably don't know it was in Beta for donkeys. I actually remember first using it in 2006. 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…

That is my recollection — the frustratingly hard-to-google Web Developer extension was the first thing along those lines I ever heard of. I continued using Web Developer for a long time after Firebug came out because I sort of wrote it off as a ripoff.

Re: Our web development workflow is completely broken

#113
post #93

Earlier quoted context omitted.

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.

Ah ok, fair enough. I'd heard that Smalltalk had a really good environment for this but I've never looked into it. Let me rephrase then. There are amazing server side REPLs that allow me to change code on the fly, why can't I change code in my editor and have it reflected directly in my browser?

You can, if you're in control of the framework you're using.

Re: Our web development workflow is completely broken

#114
post #37

Earlier quoted context omitted.

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.

I'm fairly sure that's been tried before - with XHTML2 and disappeared down some black hole never to reappear - http://www.w3.org/2004/04/webapps-cdf-ws/summary . And HTML trundled along unwanted in WHATWG through those times, scorned, rejected as inadequate and not suitable. And yet, XHTML2 got closed down, everyone switched back to the HTML path. And processes involving changing web development from an environment…

I would say these approaches were still just bandages, so it makes sense they didn't catch on. GWT, for example, was a fairly nasty leaky abstraction. I don't think it removed the need to understand the rest of the stack, and it added a whole lot of its own Java inspired complexity. XHTML wasn't solving any fundamental problems either.

In an ideal world, now that the web has shifted from being a bunch of linked documents to complex applications, we'd have a development stack aimed at developing applications, with sane means of specifying UI layout and behaviour, low overhead client-server comm protocols etc.

Re: Our web development workflow is completely broken

#115

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…

No, you're wrong. You weren't around obviously, so you probably don't know it was in Beta for donkeys. I actually remember first using it in 2006. 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…

The link for the IE Developer Toolbar in the original article carries a date of September 19, 2005 in the URL. Which makes sense, because it was demonstrated at PDC 2005, which was the previous week.

Link: http://betanews.com/2005/09/19/microsoft-issues-ie-developer...

Note also that the release notes for Firebug v0.2 state: "This is a very early release - the code is only a few days old." Whereas the IE Developer Toolbar probably began a couple of months before its first release. So even by looking at the first mention on the web, we're comparing a days-old Firebug to a fairly-complete IE Developer Toolbar.

Re: Our web development workflow is completely broken

#116
post #97

Earlier quoted context omitted.

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

> aiming away from my requirements Out of curiosity, what are your requirements? It's hard for me to imagine that LT is really aiming away from anyone :) It's a platform for building whatever workflow you could want, integrated with any system/language/service you can find. That particular aspect of it hasn't been released quite yet, but it will be the major focus of the beta.

Hi. Apologies if that came off as too curt - typed quickly on my phone. With the above said, I still light table is miles ahead of what everyone else is doing.

My background is as an architect (buildings). For me, most of the issues I'm interested in solving are to do with interaction with visual information (2d and 3d) rather than working with reams of code.

I was most excited where I saw the Light table demo where there was dynamic editing of a game (inspired by the Brett Victor video?). The more recent developments seem to have largely focussed on making it have the full functionality of a traditional editor with some additions. What I am looking for is something that can take over not just from a code editor but also take over from other kinds of programs. Examples might be something which can replace my photoshop actions palette or something where I can organise my screen to compare Google Earth and Openstreetmap data side-by-side or on-top of each other (and click on things to query what they are). Generally these are conceptually simple tasks which current tools and workflows make very difficult to implement.

I have to run but I hope the above makes sense. I'd probably need much more text for a fuller explanation. Happy to discuss.

Re: Our web development workflow is completely broken

#117
post #85

Earlier quoted context omitted.

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

Yes, I've run into issues with things running differently in an async environment (dev) and a sync environment (prod). To mitigate the issue I now throw events at key points in initialization and wait for those events to continue. Has solved my problem so far.

Using r.js in development isn't the worst idea. It's worth seeing how long it takes in order to make that decision. Compiling tpls is much faster (grunt-contrib-jst) and adding that to your grunt watch & including it directly is a good way to save time. I think it takes a long time on my end due to the complexity of the dependencies. I only include exactly what each module needs so some dependencies may be as many as 6 levels deep, or more (haven't really checked).

SPDY makes a big difference for me (big enough to ignore the problem for now) and I don't mind using a self-signed cert in dev.

EDIT: I hadn't been compiling tpls using JST in dev until I wrote this post - a great side effect is, it actually shows me now where the errors in my tpls are! Previously any tpl's stack terminated at the code that ajaxed in the tpl. This is far better for debugging and brought my DOMReady time down to about 1.75s.

Re: Our web development workflow is completely broken

#118

Earlier quoted context omitted.

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.

Ah yes true. I glossed over the CSS bit and just took in the javascript bit. I don't think TDD would fix a CSS workflow.

Re: Our web development workflow is completely broken

#119
One of the most incredible things released in visual studio 2013 is a thing called Browser Link. In the keynote they used it only for live refreshing the page. However the way it is architected adding extensions is easy. There's going to be some awesome things being built for it.

Re: Our web development workflow is completely broken

#120
post #29

JetBrains webstorm looks really cool, I wish they'd push that functionality into PyCharm.

You should try the Intellij IDEA with python and javascript plugins. They should have the same code as standalone IDEs.

I tried that, it wasn't nearly as slick as pycharm.
Post reply on HN