tag:blogger.com,1999:blog-4067982022508259050.post4306630563502400658..comments2022-04-09T06:20:55.559-07:00Comments on What's The Pointy: On Javascript DependenciesPointyhttp://www.blogger.com/profile/15300865803415441792noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-4067982022508259050.post-13429309244545146092011-08-30T00:52:44.576-07:002011-08-30T00:52:44.576-07:00Great post and, in a post-modern fuzzy sorta way, ...Great post and, in a post-modern fuzzy sorta way, echoing my own concerns about developing and scaling apps/systems.<br /><br />A key but unrecognized problem in code-creep can be the fact that it's so easy to change anything. Even if it's just me developing, it's too easy to change anything anywhere and bolt on functionality where it doesn't belong. Solution: compile functions into (e.g.) DLLs. Sounds crazy but it keeps you from breaking your own code and it makes you define small, flexible interfaces which, I think, are a key to good SW.cawoodmhttps://www.blogger.com/profile/02108527908963003806noreply@blogger.comtag:blogger.com,1999:blog-4067982022508259050.post-20779922255408211142010-08-10T09:56:42.043-07:002010-08-10T09:56:42.043-07:00I think you make some very salient points, and giv...I think you make some very salient points, and give some great insight into what making applications on the web in 2003 must have been like.<br /><br />I am a firm believer in putting together the right tools for the job. I think you hint at that a few times in this post. That sometimes, a single integrated solution has too many unnecessary parts, or too-general of implementations. I think a balance has to be struck somewhere between "full integrated framework" and "custom everything." Sometimes that can be a full featured toolkit like Dojo, or perhaps even a Cappuccino or Sencha type app. <br /><br />More often than not, though, we like to think our applications are running at a scale they will never achieve, and will have to be modified by future developers that will never exist. Obsessive planning for these things slows down and confuses development at some point. I'm not claiming to know where the line is, but I'd venture to guess, for your tango health stuff, even though $.wallflower isn't some hugely integrated solution that everyone uses, etc, it's a perfectly valid organizational choice. It makes sense for the application size, etc, and any programmer that can spend 5-10 minutes looking at it could grok it and start using it.<br /><br />As far as your dependency resolution stuff goes, it certainly depends on the app. I actually help with an extremely large java/freemarker app with a build system at work and they used to do the "chunk everything into a giant file" thing. We recently switched to RequireJS, to manage dependencies, because the scale that we had reached no longer made sense with the other way.<br /><br />TL;DR: There's a ton of value in being able to choose the correct tools for a job. Sometimes that solution is popular and cool and crazy-integrated, and sometimes its your own plugin. That's cool. People who understand JavaScript will be able to figure it out.Alex Shttps://www.blogger.com/profile/13960732063937121643noreply@blogger.com