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

101–110 of 121 posts

Re: Our web development workflow is completely broken

#101

Post by ibdknox »

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…

What is missing for you that makes it "incomplete"? We're always trying to make sure we have the necessities taken care of and I'm happy to say quite a lot of people are doing their work in LT these days - so if there's stuff we're missing that keeps you away entirely, it helps us to hear about it!

Re: Our web development workflow is completely broken

#102

Post by gkop »

romaniv wrote: post #100

I can vividly imagine this conversation: 'We have a lot of stateful frontend code that's hard to debug and test.' 'Maybe you should strive for less stateful frontend code?' 'Nonsense! We should completely reingeneer our workflows and toolchains to accommodate whatever we're doing right now, because everything else is stupid and outdated.'

The article emphasizes CSS as much if not moreso than JavaScript.

Re: Our web development workflow is completely broken

#103

Post by pnathan »

ricardobeat wrote: post #2

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

Light Table is very interesting (I've used it for some Clojure stuff), but it's competing with emacs. It's gonna be very hard to beat emacs. The legacy of thousands of lines of very useful code & unbelievable extensibility is a big one to overcome. I don't mind saying that I foresee emacs getting a lighttable-mode for dynamic languages before Light Table beats emacs. But I usually have a LightTable install on my computers; it's that promising of a project. :-)

Re: Our web development workflow is completely broken

#104

Post by progman »

pnathan wrote: post #103
ricardobeat wrote: post #2

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

Light Table is very interesting (I've used it for some Clojure stuff), but it's competing with emacs. It's gonna be very hard to beat emacs. The legacy of thousands of lines of very useful code & unbelievable extensibility is a big one to overcome. I don't mind saying that I foresee emacs getting a lighttable-mode for dynamic languages before Light Table beats emacs. But I usually have a LightTable install on my comp…

First developments of an LT mode for Emacs:

http://www.emacswiki.org/emacs/LightTable https://github.com/Fuco1/litable

Also interesting discussion at:

http://www.reddit.com/r/emacs/comments/1c923n/how_does_the_d...

I am an Emacs user for decades, and I am amazed that Emacs is still superior to almost every other editor. I think the incredible easy plugin system and many powerful plugins (like org-mode) are the reason why Emacs is still alive today. But I am curious how LT develops.

Re: Our web development workflow is completely broken

#105

Post by williamcotton »

sirwitti wrote: post #43

I like the idea of changing the dev workflow a lot. What I don't understand though is what makes the Webkit Developer Tools better than Firebug. I don't want to defend Firebug, but in my experience the Developer Tools are a pain to use in comparison to Firebug. (e.g. autocompletion of css properties and property values only works with tab and not also with return, it takes too many clicks to see the metrics,....). Wh…

If you haven't had a chance to check out the Developer Tools in Chrome Canary, you're missing out!

Check this out: https://developers.google.com/chrome-developer-tools/docs/ti...

Re: Our web development workflow is completely broken

#106

Post by davemo »

bradleysmith wrote: post #96
davemo wrote: post #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 an…

I started my career in web development in 2013, and the number of abstractions and dependencies that seemingly every toolset has can be daunting. Thanks for the fundamentals video & grunt intro, both were helpful to me.

Glad to hear my efforts have helped you out; let me know if there are any other fundamental workflow / webdev topics that you would be interested in learning more about and I will add them to my screencast backlog :)

Re: Our web development workflow is completely broken

#107

Post by mattmanser »

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…

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 IE dev toolbar, e.g.:

http://betanews.com/2007/05/10/microsoft-releases-ie-develop...

EDIT: Interestingly reading through some of the comments on the first post, it seems people claim the IE dev toolbar was inspired by http://chrispederick.com/work/web-developer/ and the initial release date for the IE Dev toolbar was Sept 2005 (see http://c82.net/posts.php?id=23)

Re: Our web development workflow is completely broken

#109

Post by williamcotton »

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.

One solution would be to stop anonymously defining modules... or...

Instead of having >200 files that need to be compiled with r.js every time, what about compiling them to intermediary builds? Abstract your code in to some bigger modules and wrap them up in a little bow with a nice interface, and basically consider that part of the code "solved" and focus only on what is currently changing or being built. Your build process should reflect this!

I've been doing this on larger projects with RequireJS and r.js and my build times are very short... it just builds from maybe 15-20 files, where a few of those files are the result of some other r.js build.

Now, should r.js possibly do things to better manage this sort of approach? You bet! There are many mature build environments that have a similar approach. Maybe r.js needs some sort of concept of "linking"?

Personally, I don't mind having to manage intermediary builds, because... that intermediary build is making something that I can use in OTHER projects... I haven't really come across a situation where pure business logic is dominating an application. Almost everything that a program does can be abstracted out and reused! I'm sure people out there can provide plenty of examples to the contrary, and I'd love to hear those!

Re: Our web development workflow is completely broken

#110

Post by williamcotton »

> When using the browser as code-editor, we are entering a world of new problems. The browser is designed to abstract away the local file system, and is based upon a read-only/execute-only model. In order to “fix” this we have introduced a new type of browser extensions, that’s trying to fix this.

It isn't really a read-only environment! It can't read anything! All the browser can do is GET and POST things...

...so maybe the problem with web development is that it is all based on files?

Post reply on HN