JAB_Creations - 7:08 pm on Oct 21, 2010 (gmt 0)

1.) It's not my fault or anyone else's if they have poor coding practices and can't keep their header and template files well organized. There is a set pattern of what goes before what. Every template system I've seen mixes what should not be mixed and the file naming scheme is just not intuitive.

Also I'll reiterate that XHTML saves an enormous amount of time by helping you catch errors much quicker, the only thing it won't catch are duplicate ID's and you can usually figure that out when you're scripting and the wrong part of the page executes with your script.

Additionally XHTML is extensible, HTML is not. I can add XHTML5 features using XHTML 1.1 and HTML8 features one day without having to do major reworking of my code. The only applicable form of difficult with XHTML is if you argue against it. A few lines of code will strengthen your coding habits and save you an enormous amount of time in the long term.

3.) In regards to innerHTML not being reliable try scripting with content loaded via AJAX and "added" to the DOM via innerHTML. It proves to be a 50/50 chance hit-or-miss in my experience. I can't think of anything really specific since working with the DOM alleviated the issues and that was about a year and a half ago for me. I may have an older build of Version 2.9 that still uses innerHTML somewhere so if you'd like me to look in to that I'll see if I can find an example.

Actually it is a proprietary Microsoft method that so happens to be supported by all the browsers. It is in a spec however it's in it's infancy and from what I've read does not have much momentum. In regards to it being added to HTML5, that's JScript, what is JScript doing in an HTML specification? Don't get me started on all the things being done wrong with HTML5! :-/

4?.) I've read that you can't actually get a 56K connection over the phone lines because of certain laws hence why a 56K modem is limited to 36K speeds. With my 56K modem I never got more then 4.7KB a sec which is 37,600 kilobits because I remember comparing the speed to when I got my first cable modem and was like whoa. :) Still that's nearly four seconds of code that itself does nothing directly so that easily implies that more code will have to be loaded and you're now at the mercy of the framework working in the browsers that you need to support. Additionally every instance of jQuery I have encountered is over 70KB minimized, not the 26KB you're talking about. Of course I'm speaking about what I have personally seen so my perspective is only my own.

Plus coding for a framework is not JavaScript, it's framework dependent code. That might be okay for a small quick and easy project though I wouldn't use it for something mission critical...plus I usually reuse my own code anyway over and over and over again so I have absolutely no need to use a framework since my code (for what I do at least) has evolved to such a dynamic point. I think for naark it comes down to how far he ultimately wants to go with his code. My perspective is simply this: the less you depend on others the greater your strengths become and the more in-demand you become to others.

In regards to dial-up market share it's still larger in countries like the UK then IE6's market share. The numbers are bound to have changed in the year since I've read the statistics. Still if you're willing to get things to work on IE6 why not get things to work for dial-up users and benefit from writing your own code directly? Value comes from having or producing what others don't have or can't produce.

Actually I've worked with jQuery in Version 2.8 of my site and while it was useful I found ultimately while working on Version 2.9 that writing my own code reduces the amount of code, increases the speed that pages load, increases my ability to code actual JavaScript, does not limit my browser support to only what jQuery will support (my extended browser support is a selling point for my business once I get it running in about a year), my code is far more reusable, there is less of it, etc etc. I simply do not see the benefits to using jQuery period. On top of that with clients who do have it I always end up saying 'no', just no. I can code something to work in less then 1KB that most people decide they need jQuery for and have seen people ask if they need jQuery just to change a className on an id, really? Granted I know there are lots of people who really make good use of jQuery to be fair though again I don't approve of it looking for IE methods and then the standards compliant methods, it's use of innerHTML, it's general bulk, it's bugs, etc.

The reason it's inelegant is because developers are ultimately usually lazy and not coordinated. To be successful you have to be strict about what you do, how you code, and not get lazy and take the easy route.

"The five essential entrepreneurial skills for success are concentration, discrimination, organization, innovation and communication." - Michael Faraday

Yes, there are plenty of regular (the use of the word vanilla is an alien context) JavaScript can be done messy as well, that comes down to if the programmer doesn't care or doesn't have enough time. What I am saying is if you master JavaScript itself instead of relying on frameworks and avoid certain things then instead of writing code every time you need to do something what naark will notice is that they will start to reuse their own code as they start to really improve. I often talk about code in contrast to grass. I use to have to code like I would always have to cut grass...now I code once and the need doesn't "grow" back. Imagine mowing your lawn in such a way that in a year it will only grow at half the rate and in three years it will always be the perfect length.

Okay, I agree to disagree too. :) Each person's path is different, the important thing is that naark can try all of the advice and figure out what works best for them. That's how I think we all learned the code in the first place.

- John