Who on earth has to justify a javascript framework to their boss? There's so much competition and, unlike in the C++ or Java world, there's no agreement about what's best. Even Microsoft and Google haven't hammered down "the solution". Many projects use 2-3 frameworks.
I've worked at (and am now working at) some pretty big companies, and I've never heard of such a practice moving over to web development. There is usually just a license audit and that's it. And if you're a consultant justifying your use of jquery to your client, you are doing it wrong. They don't care what you use, they care about what licenses you use and how it works when you're done.
I think the complaint itself is "puerile" and pretty darn shallow. The illustration may have been ugly and as one of the original people to have an official job title of "ruby on rails rock star" I'm kind of tired of the metaphor. But I'm not about to throw a giant multi-venue tantrum and poop on the jquery guy's fun.
Well, the nice thing about jQuery is that it is not exclusive. But I'm really surprised that you haven't gone and talked to the other engineers on the project and come up with a unified plan. If the majority of people want to use prototype and you can't show them why they shouldn't, then you probably don't have a good argument against them.
You have to justify jQuery to other engineers, and then your boss's opinion becomes largely immaterial unless he's utterly terribly at his job.
> last thing I want him to see some cheesy rockstar shit for a framework that's going into a massive line of business SaaS application.
If you really do have to justify it to him...
The first thing you want him to see is an unbiased assessment of the library's features and capabilities (not the least of which is its ability to play nicely with other libraries). The second thing you want him to see is other engineers agreeing to use it. That way when he saw the last thing, the rockstar, his mind would probably already be made up.
You make it sound like you have 0 influence over the course of the project you're involved with. If a silly graphic has the power to derail your framework choice, you didn't do your homework in the first place.
The actual site design is great. It was one illustration.
Why exactly should a single image on the front site make or break your technical case? Have you considered that this might be an indication that your technical case was extremely weak? Or maybe that you're being hard on anyone who exhibits even an inkling of whimsy on their project?
Sheesh. Next you're going to say their association with Devo also hurts jQuery's case because your boss hated Devo.
You're right. Sorry about the hyperbole.
Why exactly should a single image on the front site make or break your technical case? Have you considered that this might be an indication that your technical case was extremely weak?
I agree with you, of course, but I think you're underestimating how important appearances are to these middle-management types. Especially the ones at service-based companies. They will visit the website to research a tool that I want to use, and if it doesn't look professional, it will get rejected regardless of any technical argument I make. This is true for everyone, not just me.
As a developer, I don't give a shit. If they want to put a collection of the world's smelliest cheeses on their front page, that's a-OK by me. But these marketing artifacts absolutely do matter to most of the business types making decisions out there that I have to answer to.