Bumblebee

Hi folks, I'll just respond to some very good points made by Antonio and Hartley San here: My approach also, describes me down to a tee! In fact I find writing a library of my own abstracted modules during projects is a very useful way to go, although I can understand the need to fall back on Framework functions for complicated stuff. As Antonio said, another approach could be to strip down library functions to just the stuff you need, or maybe you could refer to them as a pointer for your own (perhaps more streamlined) solutions.

You make some very good points Hartley San. Yep I'm sure there are loads of people knocking out sites with little knowledge of what they're doing. And I suppose, as the internet is open to everyone, they have every right to. And I can well understand developers taking the easy way out, especially if they have a boss breathing down their neck! I just think, in an ideal world the internet would be a leaner and more enjoyable experience if developers did have the time and inclination to do the programming themselves, and it would give them much more satisfaction than just slapping in some code they've copied somewhere. And I think it is beneficial to explain that there are negatives associated with this sort of design (as Larry has said in his book), and that there is often a better and achievable alternative. My concern is that the wholesale adoption of Frameworks will be to the detriment of the internet of the future, and that we are already sliding rapidly towards this. Of course if there is such wholesale adoption, it will make it more difficult for those with more experience to spare the time to make a better effort.

Hartley San, Many thanks for providing such a detailed response to my comments. Don't worry, you would not offend anyone with them! First things first, I think what Larry means by "browser-agnostic" is that the site will work whichever browser is being used, ie the JS works cross-browser. I didn't mean to imply that frameworks do a lot of browser-sniffing however. I was referring to Larry's 1st paragraph on p 16 which appears to suggest (to my mind that is) that creating cross-browser code can be very difficult, and I was trying to point out that actually you don't need to tailor your code for every single different browser version around (aka by browser-sniffing), but you can just do a simple process of object detection without having to rely on frameworks. As for your points regarding the use of frameworks to help inexperienced users, save time in development, get design ideas, etc, all very valid points and I would agree with you. It would be foolish to suggest you should never use frameworks, of course there will be times when developers in all stages of experience might have to fall back on them, and they can be a big help in many circumstances. I am just trying to point out that it would be preferable if they are not the overriding solution, that if you can have the time and inclination to develop your own JS you will probably do a better job and maybe a more creative one, and maybe your visitors will enjoy your site more. To my mind there are far too many sites out there reliant on frameworks, sometimes to the detriment of users I think. But sadly it would be overly idealistic to expect every site to be custom-coded by the developer.

I've just been reading the "Rise of the Frameworks" section of Chapter 1, and would like to take issue with you Larry (in the nicest possible way!) because I think your comment about Frameworks being very attractive because they are designed to be browser-agnostic, could be rather misleading to newbie developers. I think I'm right in saying that browser-sniffing is very seldom used by competent JS developers now. It is in fact quite straight-forward to produce browser-agnostic code, if you apply object detection and have a test suite of browsers to check against on your computer. It does not add much to the development time and I do not think you need to fall back on frameworks for this. All credit to you for pointing out problems commonly associated with framework use, the need to become familiar with the framework language, the difficulty that might arise in finding a program that will suit your design, and the likely drop in performance associated with their use. I have seen this all to often in recent years on the internet. You find sites bloated with library functions that cater for far more functionality than the site requires. I would add another negative to your list: I suspect heavy reliance on frameworks can stifle creativity. You can become lulled into relying on the framework to provide you with ideas for your design. If you create your own JS, then your designs are only limited by your imagination. The bottom line is this: Do you want a hippo or a gazelle?