On Feb 3, 6:38 am, Chris Heilmann <[email protected]> wrote: > > Well written, robust code that uses appropriate feature detection and > > fall back strategies is not difficult to write. > > That's why the web is full of that, right? If you write for yourself or > an app for your hairdresser, yes. If you write in a company decisions > are made by committee, not driven by tech excellence. Get out of your > ivory tower and ride your unicorn down the town square and see some of > the issues the commoners have to deal with.
It is the perpetuation of these problems that guarantee they remain a problem.. > > Then you don't understand how to implement feature detection. No one > > is saying write every application from scratch, or that you shouldn't > > use any kind of library. Just don't use poorly written general > > libraries. > > 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. > Right now, you come across as someone with a massive ego who > is grumpy as people do not use his stuff or ask him to build bespoke > code. It is too easy to say something is "poorly written" [citation > needed] is what I say.> Repetition is tiresome. > > If you design an application to just use basic, simple javascript then > > you don't need complex CSS selectors, chaining and so on. You just > > need a library of basic functions that does what you need and no more. > > And that can easily be written to be cross-browser with very little > > extra effort and maintained in your (or the corporate) repository. > > By whom? You expect that the people coming after you are as gifted and > dedicated to the cause. So you'd rather not write decent code because whoever follows you won't? > 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..." > 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". If a "maintainer" uses document.write they probably shouldn't have been hired in the first place. > I left my last role as a frontend architect as I've seen over and over again > that you will not touch code that was shipped ever again unless you work > on internal products. The web gets build by many people - a lot of them > incompetent design agencies - if we can use a YUI or jQuery to at least > deliver a basic support for all browsers instead of undocumented code > magic then we are at least moving ahead The "basic support" bit is in question. If either the [insert label] general library or the "code magic" break you're probably in the same boat either way. .>> If not, which DOM traversal-only library do you suggest I use ? > > Any javascript programmer who needs a library to do DOM traversal > > should not be writing production code. It would take me 10 minutes to > > teach a programmer what they need to know to do it. > > The DOM is friggin broken and badly supported across browsers. Yes > Yes, that comes from the guy who wrote "Beginning JavaScript with DOM > Scripting > and Ajax" 5 years ago. An argument from authority is a logical fallacy. > If you really want to support browsers, then a > 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. > 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. > And personally I'd rather concentrate on building > sensible interfaces for end users rather than patching 10 year old code. If the code has worked for 10 years up til now, that deserves commendation. I sure wouldn't mind patching someone else's code once every 10 years... -- 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]
