Hacker News Reader

Repost, don't know the original author:

I agree, I can't keep up, I just finished learning backbone.js and now I've found out on HN that it's old news, and I should use ember.js, cross that, it has opinions, I should use Meteor, no, AngularJS, no, Tower.js (on node.js), and for html templates I need handlebars, no mustache, wait, DoT.js is better, hang on, why do I need an HTML parser inside the browser? isn't that what the browser for? so no HTML templates? ok, DOM snippets, fine, Web Components you say? W3C are in the game too? you mean write REGULAR JavaScript like the Google guys? yuck, oh, I just should write it with CofeeScript and it will look ok, not Coffee? Coco? LiveScript? DART? GWT? ok, let me just go back to Ruby on Rails, oh it doesn't scale? Grails? Groovy? Roo? too "Springy?" ok, what about node.js? doesn't scale either?? but I can write client side, server side and mongodb side code in the same language? (but does it have to be JavaScript?) ok, what about PHP, you say it's not really thread safe? they lie?? ok, let me go back to server coding, it's still Java right? no? Lisp? oh it's called Clojure? well, it has a Bridge / protocol buffers / thrift implementation so we can be language agnostic, so we can support our Haskell developers. Or just go with Scala/Lift/Play it's the BEST framework (Foresquare use it, so it has to be good). of course we won't do SOAP and will use only JSON RESTful services cause it's only for banks and Walmart, and god forbid to use a SQL database it will never scale

I've had it, I'm going to outsource this project... they will probably use a wordpress template and copy paste jQuery to get me the same exact result without the headache and in <del>half</del>quarter the price

The problem here seems to be that you're using HN, a site about what is new as a way of finding out what you should be working with. That's like asking an ADHD kid what game you should be playing. You'll get a different answer every 5 minutes. :-)

Source:

http://www.zemanta.com/blog/i-bet-you-over-engineered-your-s... (2 years ago, in the comments)

https://news.ycombinator.com/item?id=5206578 (1 year ago)

    I'm frankly overwhelmed of learning and being exposed to new technologies.
    The physical draining feeling of learning new keywords to fulfill the same
    urges is as if I have watched 15 years of porn following from the grainy
    days of Jenna Jameson on VHS to the heady-days of Internet dial-up gonzo
    porn of the early 2000's that really explored anal (Gauge, Taylor Rain) to
    the streaming flash videos of Web 2.0 (Sasha Grey) to the now completely
    splintered and social-mediafied porno-world with all the mind-numbing
    categories under the sun (reality, high-art, webcam etc). I'm simply
    drained and spent.

Uh...

Ah, so that's why it's called analogy!

The man really knows his porn.

Moral of the story is, if you spend the time you're watching porn on programming instead you would be a master of all these technologies.

you could also say he would be the "master of his domain".

Spending his time mastur-ing web technology fads is unlikely to be more productive than just watching the porn.

Yeah, I was not expecting that. Kind of offended. (a) I'm at work and (b) was not aware of the "splintered and social-mediafied porno-world" nor all its categories.

But props to a pun-intended use of the word "spent".

Isatmour, I apologize for offending you, I certainly didn't intend to impose pornography onto you nor condone porn addiction (for being a porn addict, I know that it is no laughing matter although I try to use humor to try to be honest and confront my issue). I guess I wanted to frame learning front-end framework as a kind of OCD/obsessive behavior similar to any positive or negative addition you or someone you know might have experienced and chose the "lowest common denominator" metaphor I could find: porn addiction. Again I apologize for this who may find it offensive or an emotional trigger. And for anyone who's reading this and have this issue, I def. recommend this book: "The Addictive Personality" (http://www.amazon.com/The-Addictive-Personality-Understandin...) which has helped me understand and reform my behavior.

Thanks, I accept your apology, though in improvement, I would focus on your writing. Habits are hard to change, but what you write is public and read by others. A careful eye (try not to post before going to bed) and use of the Edit button on HN can go a long way. Remember that not everyone has the same life and interests as you -- all we can assume is shared here is technology and business, so anything outside those realms spoken here is ... uncomfortable. I'd feel the same way if you'd talked about changes in filmmaking or fabric. Admittedly this was offensive, but it was more the bait-and-switch unexpected nature of it. I'm agreeing with what you wrote, everything's great, then paragraphs get longer and suddenly--Bam! It's not about technology but how the world is changing too fast. That's where you lost me. ;-)

It drives me nuts. I spend probably 1/5 of my time doing front-end (but have been around through all of the generations you mention) and after re-org after re-org I've finally settled on a build system with a Makefile and browserify to package things up that isn't an enormous monstrosity of 1000 different node packages and bajillion-step build progress.

Frankly, I think that a large part the problems in front-end have to do with how hard it is to write maintainable JS w/ a proper separation of responsibilities, due to the way JS files are loaded/have no coherent module system (on the front-end that is). Because there is no standard module system (and yes I know about CommonJS and AMD loaders, but both have issues), to use a given component you oftentimes have to adapt an entire philosophy of package management that can lock you out of other packaging philosophies. In the end, we have millions of front-end programmers saying, "eh it seems like to much work to integrate this packaging philosophy, I'll just write my own duplicate copy/library." So basically projects silo themselves off and share little code until someone decides on yet another package philosophy (see: http://xkcd.com/927/).

People love to write build system after build system, in every field, a fetish I've never quite understood. Makefiles build some of the most widely used/complicated packages out there.

And as a final note, I'm really excited about emscripten in allowing front-end developers to move away from designing abstractions around JS/DOM in such a way that eventually we can stop relying on JS and rely on more the same primitives we use everywhere else in programming.

>People love to write build system after build system, in every field, a fetish I've never quite understood.

I have a firm suspicion its what writing a framework, cms, or blogging platform used to be.

In time the leader will show itself and people will get the message that this project is no longer fun and trendy.

I have to agree makefiles are pretty much the be all and end all when it comes to building projects. It offers pretty much all the power you could need.

The only plausible reason for makefiles to not be suitable for a culture brought up on shiny macbooks and "GUI's" would be that not many people want to deal with the complexity which comes from having that much power.

http://www.chemie.fu-berlin.de/chemnet/use/info/make/make_16...

Take this for example. Its pretty hard to look at let alone understand. That scare is probably reason enough alone for a bunch of wheel2.0s to be created. The 183 page plain text manual doesnt help much either. Its too daunting for today's culture.

Its just not about being correct and feature complete anymore, its about having the path of least resistance. Simple makefiles are simple, but nobody upvotes a hacker news article about how amazingly easy makefiles are.

It's all just marginal convergence towards "best", and in real practice, most of this "progress" can and should be ignored. For every tool, wait it out until it's been around and still in active use/development/maintenance for at least 5 full years.

But always stay playing. Always try out the new things, because some of them may just scratch a burning itch.

Fear not age, because if you've been around long enough, and are still actively learning, all this new stuff starts looking very much like mere variations of old things.

Perhaps I'm just rusty but age has only made me cautious. I'm responsible for a rather large and complicated UI framework that we use internally. The thing I've discovered over the last 5-6 years is that APIs are volatile as are JavaScript libraries, browsers and security concerns. It's terribly hard picking something that you can rely on. Even jQuery has enough breaking changes for me to have a week long task getting past 1.4.2 on our product. We have over 400 complicated web app pages that need testing to make sure we haven't broken any edge cases.

The learning curve is tough, the maintenance is tougher and the churn is terrible. It's a living hell on a large project. It makes me long for WPF or even Win32 where 20 years without significant reengineering is a good bet.

On the web, the basic DOM API is the most stable. Sacrificing convenience for maintenance these days is what I'm for. Screw the frameworks.

The problem with the frameworks is the very definition of the word. Not every problem/process fits in the workable frame, and then you end up with a pentagon shaped framework with dingles off the end, and nobody knows what the hell you did except you. Better to just write straight prototype OOP and use a preprocessor thatll add KVO to accessors/modifiers if you really need events (which most apps do.)

Emscripten is good for that. And there are many languages that have KVO that will compile to JS using emscripten. Really, JS isn't ideal for large projects, and these frameworks are silly, because they're targeting this lowly base for UI when a better language with better standard libs could be used to do lots of the logic, ie. Clojure.

>We have over 400 complicated web app pages that need testing to make sure we haven't broken any edge cases.

Reading your comment I get the feeling the impression that testing these pages is time consuming and difficult.

What kind of QA automation do you have in place?

A lot but it's not perfect by any means and it's very time consuming as the test suites take 8h+ to run.

It the best practice of a wise developer is to wait 5 years before touching a tool then that tool will be tested only by unwise people.

Devote 2% of your time and try out some of the things once in a while; don't bet on them but at least be a small part of the community which will make them either better of fail.

This.

One mod: 5 years is a very long time in this space. Node itself is but 5-years old.

(front-end dev)

Couple years ago when Google+ was the new kid on the block, I made a tiny userscript that hooked into their DOM and cleaned the UI up a bit. You'd think this was an easy task and you'd be right except it was quite a pain in the rear to maintain the extension. Google kept changing the classes and IDs, and moved the DOM around so frequently (sometimes within hours of the previous change) that my extension was constantly broken, and all my time was spent tweaking my code to keep pace with the changes propagating from an entire team of Googlers and their automated commit bots. It wasn't long before I gave up on the effort.

Following front-end trends today feels exactly like that experience; there's a whole host of prolific authors, even teams, coming up with new approaches for almost every nut and bolt in the stack. I think for the time-constrained it's best to wait for the wheat to rise above the chaff, even it means falling behind the curve a bit.

There's a few things going on here that combine to cause this mess.

First, task runners, like templating systems and module bundlers, are easy to write so there are lots of them. Grunt in particular doesn't bring anything to the table that bash scripts don't.

Second, most open-source projects don't make their value prop clear (I learned this the hard way first-hand and I'm still dealing with it) and most people don't have a good rubric to evaluate technologies so they fall back to crappy ones like gzipped size, number of dependencies, or the twitter account of who wrote it. Increasing the level of understanding of performance and how system complexity evolves over time is an important next step for the community to take.

For example I think the excitement around Gulp is legit because the tasks are composed as in-memory streams which is a scalable way to build a performant system. Browserify not so much, since it doesn't bring anything new to the table except maybe that it's so damned easy to use ("philosophy" does not count as bringing something to the table). Webpack, on the other hand is a whole different story since it accepts that static resource packaging (not just single-file JS modularization) is a problem that needs to be tackled holistically and necessitates a certain level of complexity.

I named specific projects not because I have any vested interest in them (I don't really use Gulp for anything) but because I wanted to show concrete examples of how to evaluate technologies on real merit.

Finally, the web frontend community has a huge problem with NIH (not-invented-here) syndrome which is encouraged by npm. For example, there are lots of copycat data binding systems that claim to be "lightweight" or "simple". They're usually written by people that don't know about all of the important edge cases which necessitate certain design decisions or library size. It goes the other way too -- a lot of people are building monolithic app frameworks without doing due diligence on existing systems to see if they can be reused.

If we can slow down and try to respect what others have done and acknowledge what we may not know, I think we can fix this problem.

> Grunt in particular doesn't bring anything to the table that bash scripts don't

One thing that comes to mind is cross-platform builds, which in some scenarios is very useful.

Also, how do I call a JS function in a Bash script? There are lots of JS libraries that existed before Grunt that are useful to incorporate into a build system. If I was relying on Bash scripts, I'd have to write all sorts of wrappers in JS anyway.

#!/usr/bin/env node

What a heavy wrapper. ;-)

> Grunt in particular doesn't bring anything to the table that bash scripts don't.

Other than a simple declarative API for all of your build tasks and a huge ecosystem of tasks.

Yup, exactly. A generally clear, new-developer-need-not-know style of `grunt dev` and you're out the door. And say the new dev needs to change something once he gets running? Hardly an issue. Just look at what is essentially, for most cases, JSON.

Grunts clarity has a ton to offer. With Gulp, while there are some speed increases, that clarity and DRY mentality disappears.

Interesting point regarding npm and NIH syndrome. I think part of the problem is lack of discoverability, which has led to balkanization of the ecosystem. The next big wave is probably in someone's undiscovered Github repo, be written by someone who simply never found the current best-in-class tools.

I think JS is an interesting case study as well because it's historically with such an impoverished standard library/distribution.

I'm 33 and a frontender. To be honest, it doesn't bother me too much. I think there are a core set of skills that see you through all of the change. Things like: knowing how to work well in teams, working well with graphic designers, experience with how sites work in terms of UX, web service integration, good understanding of backend structures and HTTP, estimating on projects, dealing with clients, dealing with management ... these are the tricky things that make good developers great to have on projects I think. None of the new tooling, workflow and languages that come around are rocket science, and you can get up to speed on something in a few hours, especially if you have knowledge and experience of what came before and the problems the new tools are trying to solve. I still enjoy learning new things, I don't think we can expect the rate of change to slow down - if anything it may speed up. Its a young industry, nobody knows the right way to do things yet, let alone what the "end game" state of interactive information delivery to humans will look like!

As I've gotten older I've noticed I've become more pessimistic of changes in the field. Occasionally a really good idea comes along which sticks. A lot of the time though it feels like a new hit framework is cooked up every week, and experience has taught me that this weeks hip framework can quickly turn into last years boring support nightmare.

In general I think we're heading towards better things... you just have to watch out for the warts along the way.

> This is a tangential question, but how do front-end people feel about the constant change in the field?

I deliberately hang back on investing time in something unless it's immediately, drastically simpler than what's there now.

- My 47-line Gruntfile became a 23-line gulpfile, and I understood it better, so I learnt gulp.

- I don't see any huge advantage in using browserify, just syntactic difference, so I'm sticking to RequireJS right now.

- After reading about ractive and how simple it was (have an object, have a mustache template, you have bindings) I started using it in place of Angular.

Speed is the reason. If you have gruntfiles that rely on a lot of compilation you know the pain of 5 or 6 second build times, with Gulp it's like a half a second.

Full-stack dev that came up through the front-end ranks here - I'm in my early 30s and have been doing this in some form or another for 17 years. I started with Perl and C CGI scripts, worked with Java Swing (on the desktop) for a while, had a brief foray into MFC, did a whole bunch of PHP in college, switched to Django/JQuery while working on my startup, and now use a whole bunch of Google-proprietary techniques along with the native browser APIs.

I've found that the best way to stay sane is to ignore the hype. After having worked with a dozen or so technologies, I can say that knowing your preferred toolkit well matters a whole lot more than which toolkit you know. Nowadays I usually tend to prefer whatever is native to the platform (vanilla JS for web, Java for Android, Objective C for iPhone), because it will perform better, there are fewer opportunities for bugs to creep in, and you can access more of the platform functionality without waiting for frameworks to catch up.

It was actually uTorrent (remember that?) that caused a major shift in my thinking: before that came out I was all like "Yeah, frameworks! Developer productivity! I want to squeeze every inch of convenience out of my computer!", but then here was this program that was a native Win32 app, no MFC or Qt or Python or anything, and it blew the pants off the competition because it didn't use a framework. I didn't want to deal with Win32 at the time, but Web 2.0 was just getting started, and within a couple years I was doing a startup with Javascript games, and I found that if I wanted acceptable framerates in a game I couldn't use JQuery and had to learn the native browser APIs, and the difference between them was incredibly stark (this was pre-V8, when no browser shipped with a JIT, and I was getting about 2 fps with JQuery and about 15 with native browser APIs). And once I'd used the native APIs for a bit, I found they weren't actually that bad; they were more verbose and less consistent, but not in a way that seriously slowed me down.

I think it does take a certain amount of security and confidence in one's own abilities to do this, because it definitely makes you uncool. I've been in Hacker News threads where people are like "No. What the hell are you smoking?" when I suggest that you might not need a JS framework. But the folks who matter to me respect my abilities enough to pay me generously for them, and not staying up-to-date with the latest and greatest gives me time to cross-train in other fields like compilers, machine-learning, data analysis, scalability, UX design, management, and other skills that I've frankly found significantly more useful than yet another MVC framework. If I need to use a framework I'll learn it on the fly; I've done that for several projects, and (after I learned my first half-dozen MVC & web frameworks) it's never taken me more than a week or two to become proficient in another one.

I agree with all but will point out that a benefit to a framework or any extensible tool is community contributions and opting out to native means that you don't get that benefit. That being said, when javascript ES6 modules land it'll be much easier to reuse code and dependency on big libraries would be unnecessary, meanwhile you can use Browserify or Component that have a lot of community contributions with minimum dependencies on big frameworks or libraries

We are programmers. Our job is to create abstractions and remove repetition. I understand you're making a general point but what happens when you take your argument further? Machine code? Writing bits to a magnetic platter with a magnetised pin?

No. The goal is to find the right abstractions - the right libraries/frameworks/patterns etc. If your tools end up costing you time then the tools are flawed - not the concept of using tools.

Having opinions is fun but you misunderstood me with passion :)

I'm simply saying when we have better way to package up software on the frontend there will be less reliance on monolithic libraries and frameworks, the right abstractions will be easier to write, find, and maintain. One of the greatest things about Unix is the modularity and compose-ability and Node.js adopted that philosophy, that's why I recommended Browserify and Component. They are a way to package and distribute the abstractions you speak about.

When you start using any framework that's supposed to do the things you don't have the time to learn yourself, you take on technical debt. For example instead of learning how to create mobile web applications you start using JQMobil, Sencha or PhoneJS. Now you end up spending time to learn both the CSS, HTML stuff in addition to the framework to get the end quality you want.

I've always seen 'boutique' development as something that eventually requires transcending frameworks in favor of optimally architected code. uTorrent is an example of a high caliber of development.

In a world where people relentlessly defend good enough (generally, engineering advice on HN is often straight-up amateur hour), it's telling that great sometimes requires abandoning the tools that hipsters clamor for.

All you need is a great UI design, good architecture, and a keen eye for details.

I've always enjoyed the change and the re-start of standardization efforts reminds me of the fun of bad old days without the massive browser incompatibility. For me the transitions weren't about being "forced" to do anything but rather a continuing quest to find something that sucks less. I've been on the w3c/mozilla bandwagon since '98 so I've avoided 90% of the plugin thrashing you mention. The DOM libraries are different interfaces over the same underlying API so they work the same. For the MVC libraries, I've been exploring the space since 2008 (I was writing docs to release my version of the Backbone library when Jeremy released Backbone and his code was better) so I don't see it as new and upcoming. Having a build seemed obvious when I started writing 10k+ sloc apps since I'm not going to put it in one source file and making 30 requests for js is terrible and I had a rake script I copy/pasted around for years before the node build systems showed up. AMD always seemed like a solution in search of a problem to me and I just concatenate everything.

For what it's worth, we're about to go through another generational shift in frontend tech. There are a few major developments in the pipeline: ES6 generators and Web Components. Generators allow for different async flow control patterns [1] which greatly changes the feel when writing JS. Component systems (Ember, Angular, Polymer, React) offer significantly improved state control and huge code savings. If you aren't already using one, you will be in the near future but it's still early enough that it's unclear which will come out on top. There's a set of emerging standards work around enabling self-contained Web Components (shadow DOM, template tag, scoped CSS) but these don't dictate how you structure your code so there's still room for conflict.

[1] https://github.com/petkaantonov/bluebird/blob/master/API.md#...

I am a full stack developer and spend a fair bit of time on the front end. Like you I feel a lot of this work will be made obsolete very soon but I am resigned to the fact because it has been going on like this for years.

I find the best strategy is to wait for wider adoption and hedge your bets. Gulp looks great but depending on the amount of time you can spend on it, it's best to wait for the ecosystem to mature (more plugins, more framework support, migration of existing Grunt plugins etc). I would give it another year or so because community migration can take time (backward compatibility, dependencies, endowment effect, etc).

The other thing that works for me is to adopt frameworks with a lower learning curve even it requires more manual plumbing. Plumbing is cheap and you can always refactor. Backbone JS was easy and I am looking forward to Riot JS because it has no learning curve as long as you have a good familiarity with writing robust JS.

HTML/CSS, .net, PHP, LAMP, AJAX, Jquery, HTML5, Backbone, Grunt, PORN, Gonzo, Anal, Sasha Grey, Scala, Python, C++

Brb. Updating my LinkedIn profile, "originally a front-end developer, but later foray into Gonzo/Sasha Grey has really opened up my interest in implementing modern concurrency 'best practices' in the back-end."

What's the point of developing stuff in the first place? To make the world a better place, to learn things, to grow. Will that be accomplished so much better by switching from Perl to ASP to Ruby on Rails to Node.js to Go?

Look, there will always be a new tool|library|framework|language|paradigm that is cooler and better. If you pick the coolest language available today, you will be "so 2014" in a few years.

We need to be more pragmatic and use the tools that make our mission easier. Sometimes that mandates a complete rewrite in a new language|framework, but that is rare.

What the article calls "revolutionizing" is really not that big a deal. Maybe it makes things a bit easier, faster, prettier -- but it won't make or break your company.

The thinking might be different for behind the scene basic tools and more UI level libraries.

For this OP, the move from grunt to gulp for instance is a simplification of the build process. It requires some refactoring of the build process, but shouldn't impact the application code, the two libraries can coexist (not cooperate I guess, but at least you can set up both and use one or the other as you want), and can be tested with simple use cases first and expanded to the whole app afterwards.

The barrier to entry is low, it doesn't require much commitment and can be done on the side. I'd try to keep up as much as possible with new available tools, as long as they match the above criteria.

For libraries and frameworks closer to the UI and application structure, I have the feeling they generally need more time to pickup, learn the strengths weaknesses, deal with the quirks and bugs. Even with reasonable documentation, most of them seem to need at least a few dives into the source code to really get how they work and what they expect to be doing.

Trying Ember or Angular on a somewhat realish project takes enough time to make it a chore to try a few alternatives, I'd guess most devs would want to wait months or years to see which libraries die in infancy. I think for this space, trying more than one or two picks here and there a few months apart is just insanity, except if you really enjoy it or it's part of your job. As time goes by I feel the timespan I wait for something to see if t sticks goes longer. I remember a Jeff Atwood post [1], about how ruby is now mature enough to be taken seriously.

I think the same thought process can be applied to big enough frameworks.

Personally I'd tend to go for the libraries that are simpler or with the least 'magic' to avoid getting in situation where I invested weeks doing something and there's bug I don't know where it comes from and need to spend days on it because of the amount of abstraction going on. That's a way to mitigate risks when trying out random libraries.

[1] http://www.codinghorror.com/blog/2013/03/why-ruby.html

Sorry I'm late, but I thought I should weigh in. This problem used to frustrate me but I realised that it just isn't worth worrying about. I wrote a big whiney article about it a year and a half ago: http://danielhough.co.uk/blog/i-cant-keep-up/

Interesting question, I feel that if you are good in a particular area (Say php / css / js / html) then you will find each new component / framework actually simplifies your life or makes it easier. The trouble is if you are more of a heavy js developer and are typically labelled as a web developer. Then you feel like you have to know about SASS (css) / HTML5 video standard / Scala and everything else related to the web field!

I think that as web development grows and matures, it will finally have multiple experts who need to work together and with each expert having no problem in catching up or using the latest paradigm in their area.

I would recommend you specialize / try and learn whatever you are good at.

> I feel that if you are good in a particular area (Say php / css / js / html) then you will find each new component / framework actually simplifies your life or makes it easier.

I disagree. Frameworks/components are written by human beings; some are a good idea, others a bad idea, and any a complete mix. I would hazard a guess (stats was never my strength) that 50% of new frameworks are a bad idea and/or complicate matters down the road.

> I think that as web development grows and matures, it will finally have multiple experts who need to work together and with each expert having no problem in catching up or using the latest paradigm in their area.

We're there already. But the pace of change means keeping up is still an issue (esp once you have partner/family and don't want to spend evenings/weekends playing/learning) and actually you need to see across areas for some topics (front-end performance being one).

be realistic, this is akin to your team changing a few lines in a makefile,

sigh, javascript people,

You're like Lance Armstrong after he retired from road cycling and decided to get into mountain biking because it'd be so easy to stomp the competition in a race with merely 20 miles of distance and 5000' of climbing. Needless to say he got his ass handed to him because there was a whole world of technical skills which he did not even know existed. Riding up a rutted, rocky, rooty slope does not allow you to stand up and leverage your superior legs and lungs because guess what your back wheel just slipped out and you wasted a ton of energy falling over.

lol. i only do recreational drugs.

and i'm actually a javascript people myself. And i just moved away from grunt in my makefiles (not to that though) a couple weeks ago. my comment still stands.

> my comment still stands.

My analogy is one of the best in the history of ill-advised programming analogies, the more I think about it the better it gets (of course it may be lost on people who aren't mountain biking full-stack developers). Your comment on the other hand doesn't have a snarky leg to stand on.

I could say i'm pretty good mountain biker who is laughing at road bikers discussing if shaving a beard would trim down enough weight to win a race or create more drag.

As a neutral third party observer, I've enjoyed the exchange and only lament that if this was me at work, how much time I'd have spent on crafting the perfect comeback message to someone on the Internet and how much pride I've taken in my work and only to know in the deepest of my heart that it is only a "labor of love" like the sound of one hand clapping that no one'll ever hear or appreciate. Kudos to you both, gentlemen.