That screenshot is everything, that is the firebug output, count the lines... there is 35
Odd, it's chopped off here around the 20th item.
I blurred things as to keep the anonymity of the project
Which is fine, it would just be nice to see the file extensions so you know what the file is -- load order based on file type and code location is one way to optimize; crazy as it sounds.
if you look in my 2nd reply I give you details on file sizes and amounts of external resource calls.
Which is 1/10th what I'm asking...
Also I am not using Bootstrap, I have a class (or function if you prefer) call Bootstrapper which basically kickstarts the framework initialisation and resource loading, think of it as an entry point, and it is housed within Bootstrapper.js file.
Ah, my bad. I saw that file and with bootcrap now having a JS include, it was a logical assumption -- but again, assumption based on an incomplete picture.
I really worry as you are getting hung up on the simplest part of web design, any donkey with a keyboard can put together html (and some of those donkeys even know what a doctype is).
You would think so, but then why is it the majority of people sleazing out HTML any old way can't even follow the simplest of it's rules -- like actually using tags for what they are FOR. HTML is to say what things ARE so that when things like visual appearance are unavailable the page is still useful.
Yes there is some finesse around divs vs spans, tables vs ul etc, however you can style it however you want with CSS, make a ul look like a table, make a table look like a ul, it doesn't matter.
Unless you are a screen reader or a search engine, in which case what tags you use IS important because CSS means absolutely NOTHING to them, nor does a tags default appearance because -- Screen readers and search engines don't have eyeballs! Hence "semantic markup" -- though I've soured on that phrase and am likely going to start calling it what it truly is, "USING HTML PROPERLY".
So when you start to see HTML as fairly inconsequential and the majority of the work being JS and CSS then you start to realise that you need to put some strategy and forethought into your designs.
Which is a short-sighted pissing all over accessibility, usability AND graceful degradation, much less forgetting why HTML even exists in the first place.
CSS and JS are there to enhance functionality, not supplant it in all but the rarest of cases. Diving for those before you even think about accessible markup is like sleazing out a PSD and calling it design -- putting the cart before the horse.
Which is why I laugh when I see people using JS to do things HTML can do without it. Or using JS to do CSS' job...
CSS for example is nice, but wouldn't it be nice to be able to re-use css chunks or have css variables that can be calculated based on inputs?
You mean like by... grouping selectors and leveraging inheritance properly? A failure to do so being why halfit nonsense like LESS and SASS are popular amongst people who to be frank, haven't learned enough about CSS to be writing it? Much less knowing enough about it to even say if LESS/SASS is actually delivering any benefits?
Just more crutches for the inept that makes more work, not less; usually because of deficient education on how to use HTML and CSS.
Just because something is popular doesn't make it good... Lemming effect.
Wouldn't it be nice to not have to worry about adding and removing stuff from the DOM every time something changes? (again feel free to say no but you see where I am going here) we said YES thats a genius idea, why do I want to spend time fiddling with the lowest level of HTML manipulation when I can just provide some data and have it update for me. This is what Knockout and other modern JS view frameworks do.
... and likely in the process being inaccessible, slow, and a waste of time since you can usually do it faster and in less code without them. YMMV, but to me they are again, a crutch at best, pointless bloat recreating existing functionality at worst.
Stunning example of everything wrong with development today -- between the inept re-re inaccessible broken "I can haz intarnets markup", lack of semantic relationships, and what it has the giant pair of brass to vomit up and call the SIMPLEST of HTML structures a "form" -- that tool is more idiotic than what people were barfing up and calling websites in frontpage fifteen years ago! HELL, IT's the SAME CRAP!
Tables for layout, no LABELs, no FIELDSETs, nested tables without scope attributes, broken keyboard navigation --- what that tool "does" is such complete rubbish I pity anyone DUMB ENOUGH to use it... which means you're right, I wouldn't waste the effort on making such a pointlessly useless garbage tool. That is EXACTLY the type of nube predating garbage I'm talking about -- and if you don't know what's wrong with what that tool does, to be brutally frank do the world a favor, back the hell away from the keyboard and don't come back until you've bothered learning how to use HTML and CSS properly!
What that tool vomits up and calls markup is so disastrously bad and reeking of pre 1998 practices, that hold it up as an example of doing something that has any business even being done on a site ... wow, just WOW. Say hello to 1997 for me! I'm sure Netscape Composer 4 and Frontpage will keep you company.
If what you are doing bears any resemblence to that? Yikes. Just throw it all away now.
side note, if I did that, I'd probably send the data serialized or ASCII controlled instead of JSON, but that's just because I find JSON and XML to be grossly inefficient data methods -- which is why I only use those formats when pulling from someone else's data sources. Though really, I'd just SHOCK let the resulting form do what it does and if need be, intercept onsubmit while still letting it drop through script-less.
If you can explain to me the benefits of using raw JS and DOM manipulation with native objects vs using a framework such as Knockout then I am more than willing to hear it
Faster code execution, use less code and simpler to do it... greater likelyhood of being able to generate SEMANTIC markup and actually SHOCK use HTML tags for what they are FOR instead of being at their (seemingly halfwit) whims of abusing markup out of ignorance.
(it is 17kb by the way).
minified and gzipped it's 17k... it's 46k not counting gzip, so that's 46k of wasting battery and processing time... what's the formatted version? 200k+? (probably around 100k less comments) -- minified it's already half my unminified page allotment!
But then when I say my usual target template (not counting content) size is 72k or less in a dozen or so files, HTML+CSS+SCRIPTS+IMAGES without whitespace stripping, minification or gzip...
Kind of a laugh -- you say HTML is easy -- if so why are so many developers completely incapable of using it properly?!? To the point keyboard navigators, users on screen readers, and even search engines can't use the pages vomited up that way?
... and I do mean vomited up.