On 2/3/11, Chris Heilmann <[email protected]> wrote: > >>> Some cheese with that whine? All the big libraries are open source and >>> very much in use. If you really are that gifted and care about what >>> people use on the web, file bugs and fix these oh so poorly written >>> libraries. >> I see comments like this often, but this is easier said than done and >> I don't mean because of some technical difficulty but rather due to >> politics of each major library's community. You can check CLJS for >> many instances of this. >> > How exactly is filing bugs and fixing things you obviously see are wrong > hard to do? My point is that ranting about something without bringing up > WHAT really is broken is just noise. And appears arrogant. "I know the > solution and can do better, but I won't tell you". > Who are you quoting?
And I've filed well over a dozen bugs on YUI. I've submitted patches and even forked YUI so that I could help with that (my Github username is GarrettS) YUI bugs didn't get fixed. I've gone into more detail about that on this very list. [...] > No, but I'd rather write code using a library that serialises browser > support for me and is documented than write my own stuff and not > document it. A library is not only code, a library is also support, > maintenance and documentation. > Sure, sounds great. And the code should be efficient with no extraneous cruft. But then it won't fulfill every scenario. However, the ones "in the trenches" are more closely connected to the problem, and (ideally but not always) to the problem space. If the guys working on building the app need an abstraction to handle a bit of functionality (and for anything having even a modest degree of sophistication, they will) then they should write and organize it into their codebase. That is essentially the idea behind writing an abstraction. Factors that come into play with that are reusability and encapsulating the parts that vary. I've seen reusability go either way -- either something is not reusable at all or it has had code added to accommodate cases for which it most surely will never be tested. > >>> Most of the big projects I built went into >>> maintenance mode sooner or later. At least with libraries like YUI or >>> jQuery they didn't mess around with the core code of the library. >> I guess the word YUI or jQuery is an appropriate synonym for "warning: >> keep out or you might break the duct tape..." >> > Erm, YUI is the library the Yahoo front page is built with - the largest > web site on the web. If you build something bigger, that works for a > more diverse market and across more locales then you can claim other > things are built poorly. I covered this earlier this week. One is not required to build a bigger outhouse to claim Yahoo frontpage stinks. See validator.w3.org and read up on how invalid HTML isn't standardized. Judging libraries by designers using 12 > different widgets on one page to achieve a certain look and feel is not > giving them the respect they deserve. > I didn't understand the part about libraries by designers. I think that I probably did not interpret that sentence as what you meant. > >>> FYI: I don't like chaining and if you write massive CSS selectors you are >>> doing >>> it wrong. >>> >>> With your own solutions you will find document.write() hell added by >>> maintainers sooner or later. Wake up and smell the corporate mandate: >>> "release this quick - maybe you get a chance to fix it later". Perhaps corporations are too short sighted to see the costs of building maintenance nightmares. >> If a "maintainer" uses document.write they probably shouldn't have >> been hired in the first place. > > And how exactly are we the ones hiring the maintainers? Of course they > shouldn't be hired, but they are cheap and this is what counts high > above. That's why it is important to build on something that is proven > and documented rather than "our own awesome".library that polyfills the > browser differences for you makes a lot of >>> sense. Check out John Resig's "The DOM is a >>> mess":http://ejohn.org/blog/the-dom-is-a-mess/ >> I think RobG's point is that you should focus on code that polyfills >> RELEVANT differences instead of possibly all possible differences. >> > That is why YUI is modular, I agree that the "kitchen sink" approach of > some libraries is annoying. The same applies to HTML5 polyfills. If you > add 12 scripts and 3 different styles just to make IE6 behave then > something is wrong. > >>> And don't get me started on Events. If you don't simulate them you can >>> never do proper event delegation with keyboard access for example. >>> >>> Of course you can teach DOM in 10 minutes. The issue is that applying >>> DOM properly needs 3 years of experience on how browsers fail to >>> understand it. >> So put that on the job requirements posting. >> > Again, have you ever hired people? Sorry I missed to see how that question is relevant. I'm not saying yo don't have a point but probably you could be a little more on it. Or mabye I'm just being dense. What tech people put in job > requirements is not what is going live in a lot of cases. > http://www.readwriteweb.com/start/2011/01/the-valley-lacks-flexibility-not-talent.php > Is there a supporting argument in there that needs to be gleaned? I'm not sure how the article at the URL relates to the former sentence. -- Garrett -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
