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

91–100 of 121 posts

Re: Our web development workflow is completely broken

#91

Post by aidos »

EzGraphs wrote: post #74

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

Not to take anything away from this but that's not really achieving the desired effect. There's still a browser refresh happening so you lose your state every time. You're still stuck in the same cycle. In an ideal world you would be able to change code in your editor and have those changes reflected within the objects already loaded in your browser.

Re: Our web development workflow is completely broken

#92

Post by agentultra »

A remote protocol is super-handy. Anyone who has used CL w/ SLIME and a compatible editor can attest to this. There's even a little project called slime-proxy[1] which proxies the javascript compiled from parenscript in a REPL to a connected browser via websockets. It is a much more elegant way to develop applications for the browser than the reloading hacks that are popular today.

[1] https://github.com/3b/slime-proxy

Re: Our web development workflow is completely broken

#93

Post by aidos »

swannodette wrote: post #83
aidos wrote: post #78

Earlier quoted context omitted.

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.

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?

Re: Our web development workflow is completely broken

#95

Post by stefek99 »

http://yeoman.io/ tries to solve it... (like it mostly for its live reload feature)

Here is another great example - http://remysharp.com/2012/12/21/my-workflow-never-having-to-...

My two cents: find solutions... People who make tools are just like us, some empathy, accept what you cannot change :)

Re: Our web development workflow is completely broken

#96

Post by bradleysmith »

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.

Re: Our web development workflow is completely broken

#97

Post by ibdknox »

twelvechairs wrote: post #71
SCdF wrote: post #54

Earlier quoted context omitted.

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

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

Re: Our web development workflow is completely broken

#98

Post by tlrobinson »

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…

"the issue of losing JavaScript state upon reload"

Is this really that desirable? I can imagine a lot of scenarios where this would cause unexpected behavior.

Most other platforms don't support this, do they?

Re: Our web development workflow is completely broken

#99

Post by edwinyzh »

Yes, the workflow is broken, and that's why I've been working on LIVEditor (http://liveditor.com) and the past 2 years!

I'm so glad that Kenneth's post just proved my concept!

LIVEditor combines a Scintilla-powered code editor together with a Chromium-powered browser, it's very deeply integrated since it's a same software.

Re: Our web development workflow is completely broken

#100

Post by romaniv »

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

Post reply on HN