Three Routes to Spaghetti-Free Javascript
1–10 of 18 posts
Re: Three Routes to Spaghetti-Free Javascript
#2Not sure if the title is indicative of the tutorial's true usefulness. The information on asynchronous function calling alone is worth the click-through.
I wasn't aware of any of the three javascript packages (are they libraries? frameworks? seems like they're not really), and anyone looking to improve their asynchronous javascript writing skills and readability should take a look. The author admits that debugging could be an issue since these packages all generate new javascript from your current code, but the concepts look very promising.
Re: Three Routes to Spaghetti-Free Javascript
#3Not sure if the title is indicative of the tutorial's true usefulness. The information on asynchronous function calling alone is worth the click-through. I wasn't aware of any of the three javascript packages (are they libraries? frameworks? seems like they're not really), and anyone looking to improve their asynchronous javascript writing skills and readability should take a look. The author admits that debugging co…
Agreed. Extremely interesting and useful ... and not at all what I expected from the title!
Re: Three Routes to Spaghetti-Free Javascript
#4But why isn't jQuery 1.5 mentionned? See this:
http://www.erichynds.com/jquery/using-deferreds-in-jquery/
Re: Three Routes to Spaghetti-Free Javascript
#5I've written a library for internal use (that I'm waiting for work to agree to open source) that basically lets you bundle a group of asynchronous calls into a single callback. I prefer this method because it doesn't try and hide the asynchronous nature of the code, it just frees you up from having to nest your callbacks N deep when you require the output from all N asynchronous operations to continue. Wondering what others think about this? Do folks prefer the methods in this article that let you hide the asynchronous nature of some code?
Re: Three Routes to Spaghetti-Free Javascript
#6I've written a library for internal use (that I'm waiting for work to agree to open source) that basically lets you bundle a group of asynchronous calls into a single callback. I prefer this method because it doesn't try and hide the asynchronous nature of the code, it just frees you up from having to nest your callbacks N deep when you require the output from all N asynchronous operations to continue. Wondering what…
It's been done. One of the best libraries for managing asynchronous code in JS without hiding it away is http://github.com/caolan/async
I agree wholeheartedly, by the way. There's way too much scope for leaky abstractions when you try to hide away the true nature of asynchronous code.
Same reason, I think, why most people are lukewarm about using continuations in web development, like e.g. Seaside does: in principle, very neat, very clean, but it hides away a fundamental aspect of how the web works, which can lead to all sorts of unforeseen behavior re. caching, debugging et cetera.
Re: Three Routes to Spaghetti-Free Javascript
#7I've written a library for internal use (that I'm waiting for work to agree to open source) that basically lets you bundle a group of asynchronous calls into a single callback. I prefer this method because it doesn't try and hide the asynchronous nature of the code, it just frees you up from having to nest your callbacks N deep when you require the output from all N asynchronous operations to continue. Wondering what…
It's been done. One of the best libraries for managing asynchronous code in JS without hiding it away is http://github.com/caolan/async I agree wholeheartedly, by the way. There's way too much scope for leaky abstractions when you try to hide away the true nature of asynchronous code. Same reason, I think, why most people are lukewarm about using continuations in web development, like e.g. Seaside does: in principle,…
Yeah, I assumed there had to be libraries to do this already, but didn't come across anything that did what I wanted. I'll check out async though, thanks for the heads up.
Re: Three Routes to Spaghetti-Free Javascript
#8[deleted]
Re: Three Routes to Spaghetti-Free Javascript
#9I've written a library for internal use (that I'm waiting for work to agree to open source) that basically lets you bundle a group of asynchronous calls into a single callback. I prefer this method because it doesn't try and hide the asynchronous nature of the code, it just frees you up from having to nest your callbacks N deep when you require the output from all N asynchronous operations to continue. Wondering what…
It's been done. One of the best libraries for managing asynchronous code in JS without hiding it away is http://github.com/caolan/async I agree wholeheartedly, by the way. There's way too much scope for leaky abstractions when you try to hide away the true nature of asynchronous code. Same reason, I think, why most people are lukewarm about using continuations in web development, like e.g. Seaside does: in principle,…
"There's way too much scope for leaky abstractions when you try to hide away the true nature of asynchronous code."
Done properly, that's not terribly true. Done properly, correct code transformers can actually bring you a lot of power, such as handling exceptions correctly across asynchronous boundaries or enabling much more powerful control flows, such as being able to freely pass in callbacks that themselves may have asynchronous functionality, layered arbitrarily deeply. The only thing that can "leak" is exactly where the asynchronous breaks occur, but it's not that hard to see that.
It's quite debatable that "the true nature" of asynchronous code is in the manually-scheduled hacked up code that you write by hand in Node.js or similar tools. Other environments that don't require that make a good case for saying that the "true nature" of asynchronous code looks like the synchronous code, only with capable scheduling, and the real "leaky abstraction" is the way your terrible, terrible language runtime scheduler is poking out and requiring you to manually transform your relatively simple code into a spaghetti mess to satisfy it. There's your leaky abstraction, and what leaks out is daggers slicing your code to ribbons.
Re: Three Routes to Spaghetti-Free Javascript
#10Could we make getTitle a method of some webpage object? Then the event handler could set the webpage instance's title attribute. Webpages could have class variables that kept track of the total number of webpages created and the total number that had titles.