1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

A PDO class to make it easy on newbies and lazy coders

Discussion in 'PHP' started by eritrea1, Oct 8, 2013.

  1. #1
    I am not sure, if I am misusing the purpose of this forum, by asking people to see this 1-file-class, I contributed to make the task of writing a pile of PDO statements into one short line of snippet.

    The code is hosted in Github: https://github.com/simon-eQ/PdoNoodle

    It would be awesome, if anyone can just point out any issues or feedbacks..


    Btw: The idea is to allow users to execute PDO commands easily, as in:
    SEMrush



    $select = $PdoNoodle->doLazy('SELECT * FROM users')->where('name = ?', $_POST['Simon']);
    Code (markup):
     
    Solved! View solution.
    eritrea1, Oct 8, 2013 IP
    HolyRoller, ThePHPMaster and ryan_uk like this.
    SEMrush
  2. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,976
    Likes Received:
    1,635
    Best Answers:
    233
    Trophy Points:
    515
    #2
    first up, I'm not sure the point since one of the whole reasons execute is separate on statement is you can re-use the SAME statement over and over... and really if I were to do it as a single command, I'd make it a single command instead of two separate methods... In fact, I do that in my extended PDO object with ::prepExec($query,$data) ... actually it's a bit more complicated, but that's because I use named queries to help isolate code and make cross-engine support easier.

    ... which is the other thing, rather than making a new/separate object, why not just extend PDO?

    Also, not wild about $db being public in scope -- but I tend to be VERY paranoid about letting anything database related out of local and/or private scope.

    I started writing up a series of articles back in February about it, I really should finish up the other two parts and post them. Part 1 is over here on a friends forum:
    http://techtalkin.com/Thread-Extending-PDO
     
    deathshadow, Oct 8, 2013 IP
    eritrea1 and HolyRoller like this.
  3. eritrea1

    eritrea1 Active Member

    Messages:
    182
    Likes Received:
    9
    Best Answers:
    2
    Trophy Points:
    70
    #3
    I knew the subject of extending the PDO class would come up. I thought about that for quite a while, but I am too noob to fiddle with the class at the moment, but that is the plan. I'm not sure, if I understood "re-use the SAME statement over " meant, but the fact I made it two methods instead of one, is because I wanted to give users the ability to break the query in pieces, just in-case they have a very long query.

    The link was awesome thought, I am surely going to read it right now.

    thanks
     
    eritrea1, Oct 8, 2013 IP
    HolyRoller likes this.
  4. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,976
    Likes Received:
    1,635
    Best Answers:
    233
    Trophy Points:
    515
    #4
    One of the things about prepared queries a lot of people don't realize is you can prepare once, and then re-use it with different data. A great example of this being handy would be if you wanted to just plug in 100 dummy users for testing to a table:

    <?php
    
    $statement = $db->prepare('
    	INSERT INTO users (
    		name, joinDate
    	) values (
    		:name, NOW()
    	)
    ');
    
    for ($t=0; $t<100; $t++) {
    	$statement->execute(array(
    		':name' => 'Test User ' . $t
    	));
    }
    
    ?>
    Code (markup):
    One query, multiple executes with different data. It's part of why prepare and execute are separate statements.
     
    deathshadow, Oct 8, 2013 IP
    HolyRoller and eritrea1 like this.
  5. eritrea1

    eritrea1 Active Member

    Messages:
    182
    Likes Received:
    9
    Best Answers:
    2
    Trophy Points:
    70
    #5
    But, I don't see why such statement is impossible with my class. All one has to do is run the a query inside a loop as you did.
     
    eritrea1, Oct 8, 2013 IP
    HolyRoller likes this.
  6. xtmx

    xtmx Active Member

    Messages:
    359
    Likes Received:
    12
    Best Answers:
    4
    Trophy Points:
    88
    #6
    The difference involves the way prepared statements are handled. When preparing a statement, the database engine works to understand the query, making subsequent uses of the statement faster. If you prepare a statement multiple times, the database engine must work to understand the query multiple times, making it slower than if you executed the same statement multiple times with different data.
     
    xtmx, Oct 8, 2013 IP
    HolyRoller and deathshadow like this.
  7. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,976
    Likes Received:
    1,635
    Best Answers:
    233
    Trophy Points:
    515
    #7
    What XTMX said. Prepared queries are part of the engine -- though they can and often are emulated by the driver. (the 'emulation' being semi-broken too). You often have to ini_set it to not use the emulation to get prepared queries working properly with statements like LIMIT.

    One of the reasons it's faster in-engine is as XTMX said is it only has to parse the query once, then plug in the values as needed -- this is not only faster code-wise, it gives another boost since most all SQL engines transmit data over the network -- even when running on the same machine it's treated as a LAN connection. When you run the same query more than once using prepare it results in less data being sent over the network. (same reasoning as to why it's not a great idea to transmit markup via AJAX).

    Really, I don't see how making it one giant long line is easier than two separate statements anyways. Looks more confusing and like more work to me. Really, how is this long run-on sentence of:
    $select = $PdoNoodle->doLazy('SELECT * FROM users')->where('name = ?', $_POST['Simon']);
    Code (markup):
    any simpler/easier to follow than:
    $statement = $db->prepare('
    	SELECT * FROM users
    	WHERE name = :name
    ');
    $statement->execute(array(
    	':name' => $_POST['Simon']
    ));
    Code (markup):
    or as I'd extend PDO with a prepexec method:
    $statement = $db->prepExec('
    	SELECT * FROM users
    	WHERE name = :name
    ', array(
    	':name' => $_POST['Simon']
    ));
    Code (markup):
    But I say the same thing about the asshattery of stuffing all of one's CSS properties on a single line -- where it ends up illegible hard to follow gibberish. The ENTER and TAB keys are your friends... no matter what the re-re's who waste time and effort white-space stripping to sweep deep rooted problems under the rug will tell you.
     
    deathshadow, Oct 9, 2013 IP
    HolyRoller likes this.
  8. HolyRoller

    HolyRoller Well-Known Member

    Messages:
    552
    Likes Received:
    27
    Best Answers:
    1
    Trophy Points:
    150
    #8
    I think I can see both sides on this, while what xtmx and deathshadow say is correct, I can also see from eritrea1 point of view, in the respect that it makes it very easy for someone who has never used PDO before and can't be bothered to learn to use this method instead of traditional and less secure methods MySql methods.

    As a lazy solution to converting to PDO then I think it is good, ultimately it would be better if people just learn't the correct way, but as an alternative and with some refinement, I can see this having some use.
     
    HolyRoller, Oct 9, 2013 IP
    eritrea1 likes this.
  9. Strider64

    Strider64 Member

    Messages:
    40
    Likes Received:
    13
    Best Answers:
    1
    Trophy Points:
    25
    #9
    Lazy programming just leads to bad code and poor security, learning how to code correctly in the first place takes effort. However, in the long run it pays off for a person will have good code and better security (well technically anyways).
     
    Strider64, Oct 9, 2013 IP
    ryan_uk and HolyRoller like this.
  10. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,976
    Likes Received:
    1,635
    Best Answers:
    233
    Trophy Points:
    515
    #10
    ... and that is precisely what always gives me trepidation about 'frameworks' or 'trying to make it simpler for beginners' -- and I DO consider those two separate things. Frameworks when used by people who should know better is just a lazy shortcut, than leaves you not really understanding how anything works. Usually by the time you are qualified to decide if a framework is safe, good and worth using -- you realize it's simpler and faster to just work without it. Worse, beginners see the so called "easy" framework, and all it does is prevent them from ever learning how anything really works; which is far, FAR worse.

    In PHP, frameworks aren't as bad in that department as say... CSS or JavaScript, where they are far, FAR more insidious. CSS frameworks like Bootstrap or Blueprint for example usually piss away bandwidth for nothing, rely on presentational use of classes and markup, and on the whole just piss all over any page built with them. On the scripting side garbage like Prototype or jQuery just encourage people to use scripting to do CSS' job, slap animated garbage and elements on a page that have zero business on websites in the first place, or to piss all over accessibility with idiocy like AJAX loading page content with zero scripting off fall-backs. Gets even worse when the two are combined as a single entity... take the steaming pile of manure known as YUI. It's systems like that which are the pinnacle of developer ineptitude, and it's why anyone advocating the use of such 'frameworks' really needs a good swift kick in the crotch.

    I don't entirely think this is headed that direction -- but it's gonna take a good deal of work AND common sense to avoid that fork in the road.
     
    deathshadow, Oct 9, 2013 IP
    HolyRoller likes this.
  11. HolyRoller

    HolyRoller Well-Known Member

    Messages:
    552
    Likes Received:
    27
    Best Answers:
    1
    Trophy Points:
    150
    #11
    I've always found it easier to just code things straight and haven't tended to use any frameworks, but I find there is a continual push to work with frameworks, be it bootstrap or zend or jquery. In fact every job seems to require at least one of these. A short while back, I created a simple javascript slideshow for a site, only to be told I would have been better installing xyz and using this jQuery code.
     
    HolyRoller, Oct 9, 2013 IP
    deathshadow likes this.
  12. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,976
    Likes Received:
    1,635
    Best Answers:
    233
    Trophy Points:
    515
    #12
    I get that **** a good deal too -- even if you are functionally identical, even if you are faster/better performing, even if it's less code NOT counting the stupid library/framework against it... It's why jQuery is turning into a sick buzzword as most of the time people say "use jQuery" -- the real answer is "Don't..." Don't use jQuery, don't piss all over the page's accessibility with it, and if it REALLY belongs on the site, you can probably develop it faster, leaner and more reliable without it if you have ANY clue how to actually write JavaScript. Of course, there's the problem -- the majority of people using jQuery don't know enough actual JavaScript, and are so ignorant of accessibility they have no business developing jack **** for websites.

    Before he passed, Dan Schulz joked that he was going to start treating jQuery the way he did HTML 5... Which is to say include the library and then not use it... Just like coding a page as XHTML 1.0 Strict and then slapping a 5 doctype on it since most clients are too stupid to know the difference. (and therein ignorant of whether or not they are falling for scam artist buzzwords instead of the tech they request serving a legitimate purpose)

    Really is the danger of frameworks -- people saying "I want jQuery, Bootstrap and Codeignitor" just because they've heard the terms in passing, not because they have the slightest comprehension of what they are, what they do, or why they should or should not be used... -- edit -- and I really would toss HTML 5 on that list of sick buzzwords akin to web 2.0. As I often say, the province of those who think they can get sound technical advice from the pages of Forbes, which is akin to getting financial advice from the pages of Popular Electronics.
     
    Last edited: Oct 9, 2013
    deathshadow, Oct 9, 2013 IP
    ryan_uk and HolyRoller like this.
  13. HolyRoller

    HolyRoller Well-Known Member

    Messages:
    552
    Likes Received:
    27
    Best Answers:
    1
    Trophy Points:
    150
    #13
    I wrote some code the other day at work, some really simple javascript, then I was away on holiday for a few days. Other developer then informed me he had fixed/improved some of my code. I checked and he had changed all my javascript to jQuery. In fact many people are being taught that coding in PHP, Javascript, etc. without using a framework is old school and dated.
     
    HolyRoller, Oct 9, 2013 IP
    deathshadow likes this.
  14. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,976
    Likes Received:
    1,635
    Best Answers:
    233
    Trophy Points:
    515
    #14
    Instead of being taught using frameworks is a lazy sleazy crutch that harkens back to the worst of 1970's mainframe coding practices -- where you're often stuck wondering if these people get paid by the K-LoC... Where developers would put two or three lines of comments between every line of actual code since they were literally getting paid for every thousand lines total; was always a joy to go into an old DiBol, FORTRAN or Basic program and make it run 20 to 30 times faster by deleting all the comments. (... and far more effective than the re-re whitespace stripping of today)

    wow... starting to date myself here...
     
    deathshadow, Oct 9, 2013 IP
    HolyRoller likes this.
  15. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,630
    Likes Received:
    724
    Best Answers:
    152
    Trophy Points:
    470
    #15
    I do agree with most of what you're saying, albeit, again, you come across too harsh. You should consider offering some weighted arguments, instead of just bashing everything arriving in the last 5-10 years.

    As for PHP frameworks, jQuery etc. it's a fact that they often contain functionality which simplifies coding. However, with the PHP-frameworks, that usually involves learning the framework's way of coding - which I've never really understood - why learn the framework, when you can just learn regular PHP?

    As for jQuery, I think you're wrong. Yes, you can do all of it in regular js, of course. However, getting to learn, find proper guidance, and actually build something in pure js, gets harder and harder. jQuery is more or less a defacto standard nowadays, and I don't really see why it's a bad thing - the libraries available makes creating proper webapps and extended functionality a breeze, and provides more time to perfect solutions, instead of trying to figure out why this and that doesn't work as it should.

    While creating a timesheet for multiple users, with the ability to coordinate shifts and users across several domains, I was very happy that jQuery was there - if I would have had to manually write all those functions for dragging, dropping, talking to databases, updating, checking multiple instances etc. I wouldn't have been done yet.

    jQuery is quick - it's easy to find proper tutorials, and there are a lot of plugins which work "out of the box", without the need for much else. Of course there are plenty of room to improve on many of these, but that's the beauty of it - if you know what you're doing, go ahead.

    As for the removal of whitespace etc., why not? The code is not meant to be looked at after it's in production, and there are plenty of parsers which provide this at release. Of course it's annoying as fuck if all you wanna do is have a look at a function or something similar, but hey, that's what Firebug is for.

    And, seriously. Let XHTML go. Really. It's old as fuck, and has more or less never been used as it was intended, and is annoying as fuck to update to a more recent HTML version - for instance HTML 5 ;) And since XHTML 2 never seems to get released...
     
    PoPSiCLe, Oct 9, 2013 IP
    eritrea1 likes this.
  16. Strider64

    Strider64 Member

    Messages:
    40
    Likes Received:
    13
    Best Answers:
    1
    Trophy Points:
    25
    #16
    I had an instructor that I thought taught web design & development properly, by that I mean HTML5 was in its very early stages (still kind of is) and she used the html5 doctype. However, she taught us to treat the code as HTML4 and told us about the new HTML5 tags. She even stated that they still haven't agree on <section><article><aside>, etc.. tags, what the heck? How can any programming language not come up with a standard before putting those out there? It's like putting the cart before the horse in my opinion. Sorry, going off topic.....:confused: Now back to PHP PDO
     
    Strider64, Oct 9, 2013 IP
    eritrea1 likes this.
  17. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,976
    Likes Received:
    1,635
    Best Answers:
    233
    Trophy Points:
    515
    #17
    Show me something good, and I'll not Bash... CSS3 for example is great; particularly with Mozilla, Opera and Google giving vendor prefixes the finger... just in time for M$ to start using them :/ -- and of course Apple is now treating Safari like Microsoft did IE6.

    Unfortunately most of that is BECAUSE of jQuery and everyone and their brother using it without first understanding JS in the first place... which is why we're now seeing massive scripts to do what half the non-JQ pure JS code could handle. It's like people diving for jQuery before they even understand HTML and CSS, which is why you see so damned much jq these days doing CSS' job.

    Assuming you believe web-apps have any business even existing -- I mean if you're going to use it for goofy in-house crapplets, fine... but I'd say 90% of the crap people sleaze out their websites with using jquery could be done with less or even no scripting.

    But of course if you're making a WEBSITE, and you care about accessibility, if you can't make it work without scripting FIRST, you probably have no malfing business even making a website in the first place!

    That's a difference though between websites and applets -- the latter just piss me off in most cases -- take webmail which a decade ago was seated to relegate mail cleints to the dustbin -- and now with the scripttards smearing their dung covered boots all over the carpets on systems like Y! mail, gMail, Live Mail, and every other damned webmail service, I've been sent screaming back to the warmth and comfort of mail clients. (another thing I'm pissed at Opera about with 15+)

    Where I'm wondering why you'd need drag and drop on a timesheet application... or client side talking directly to databases... unless you've bought into the 'pageloads are evil' lie or it's strictly an in-house crapplet where you have 100% dictatorship and could give a flying **** about accessibility... Which I realize do exist; EXACTLY the type of in-house crapplets that resulted in many companies not being able to upgrade past IE 5.5 or IE6 for a decade or more -- but of course memories are short.

    Every time I see the words 'quick' or 'easy' in reference to jQuery... I keep feeling like it's a Montoya-ism... You keep on using that word...

    Yeah, who cares if you end up with dozens or even hundreds of separate files in multiple megabytes of download, and a site so inaccessible, crippled and useless NOBODY wants to visit it, and nobody will unless your content really is THAT DAMNED GOOD... or if it's a in-house crapplet where you can make your employees suffer through it's use "because the boss says so" no matter how useless, slow and crippled it is. (see the poor shmucks sitting in AT&T call centers and the BS they have to put up with -- between new standalone metro craps and decade and a half old IE 5.x activex sitting side by side on the same box...)

    Of course again, that by itself whitespace compressed jQuery is 50% my allowance in bytes for a template's HTML+CSS+SCRIPTS+IMAGES, it's not like you're going to see me endorsing it any time soon -- particularly with two thirds or more it's codebase being redundant to a simple class swap and CSS3 (fadein, slidein, etc) or does the exact opposite of what the ECMA has been telling us not to do for over a decade. (.html == innerHTML == /FAIL/). But again, I'm one of the nutters who's now coding using "use strict" -- even if I disagree with them on "with".... much less idiotic crap that pisses all over a page's functionality and usefulness like "jQuery.ui" which by itself compressed is larger than I'd ever allow a normal page on a website to reach.

    ... and that's without even talking about it sucking laptop/mobile batteries dry for nothing of any real value for most websites it's sleazed into any old way by people not really qualified to have websites in the first place.

    Whereas I'm of the opinion if you need to use Firebug on your own code, you don't know how to code. Only thing I've ever needed it or dragonfly for (I prefer the latter) is cleaning up other people's messes when hitting up against the "Don't tug on that" scenario.

    XHTML 1.0 completely delivers on what it is FOR. A reformulation of HTML 4 STRICT in a XML namespace -- bringing the clear consistent rules and possibility of parsing it as XML to the board. It was NEVER meant to allow full XML use or the XML application nonsense (which is why no matter what the XML-tards say, it IS 'real' XHTML when served as text/html -- which is just as ignorant a BS as the dipshits who wonder why you can't <div /> or <script /> as they never took the time to learn what a 'empty element' means in the spec!). Hell, the XML application nonsense is exactly why XHTML 2 was doomed from the start... unfortunately with most people having their heads full on wedged up HTML 3.2's rump and barely grasping the concepts of STRICT, concepts like strict well documented, consistent structural rules end up in the same junk bin as semantics, separation of presentation from content, graceful degradation, accessibility -- and all the other things the majority of HTML 5-tards and script-tards throw in the trash daily. But of course, that's quite obviously HTML 5's audience with all the new tags that are either redundant to existing tags (NAV, SECTION, ARTICLE), presentational by their very nature (ASIDE), or the new loosened structural rules that basically tell people "Go ahead and sleaze out the markup any old way. Logical document structure? Who needs that?!?"

    In that way 4 Strict and by extension XHTML 1.0 Strict are far, FAR out in front of HTML 5 in terms of being "new" -- since 5 is quite literally 3.2 in drag on the philosophical level -- it's the worst of 1990's practices and throwing most all the progress of the past decade in the trash. The ONLY way you could see benefit from it is if you never embraced STRICT, never grasped proper semantics or document structure, never fully understood the reason for the separation of presentation from content, and never once grasped accessibility or used alternative browsing methods.

    I'll gladly move on when they give me something BETTER to move to, but much like the steaming pile of manure known as Opera 15 through 18 (aka Chrome with the Opera logo slapped on it. I wanted a pathetic crippleware UI, I'd just use Chrome)... I don't see the 'new' delivering on that at all, at least in terms of actually writing markup and useful accessible pages.

    Oh, and there's no such thing as "too harsh" when being honest -- much less being sick of sleazeball shits and being the one most people come to to clean things up after some inept re-re pissed all over a website with half-ass BS like jQuery, Prototype, HTML 5, etc... though I swear the past... year and a half I'm stuck wondering just how the **** most "developers" and "designers" get jobs without being fired or sued for ineptitude in less than 8 hours... but then I always underestimated the power of shoving one's nose up the typical suit with a checkbook's rectum. A skill I quite obviously never mastered.

    ...and yes, I was just making quotes in the air with my fingers.
     
    Last edited: Oct 9, 2013
    deathshadow, Oct 9, 2013 IP
    Arick unirow and ryan_uk like this.
  18. eritrea1

    eritrea1 Active Member

    Messages:
    182
    Likes Received:
    9
    Best Answers:
    2
    Trophy Points:
    70
    #18
    Thanks everyone. This thread has a lot of good feedback, insights and last but not least, arguments against and for using frameworks. Although, on the subject of using frameworks, I'm highly on deathshadow's side of the argument, namely because frameworks force you to learn about the frameworks and not the real language itself, which is pity, since a real concept of programming lies on the language itself and not some framework made by someone, in which you have no idea how things are running behind the process. So people who resort to using frameworks are basically progressing towards a wysiwyg-type of approach instead of pure programming. I'm really not fan of the idea, having to use the whole jQuery library, just to do simple AJAX requests, even though jQuery handles cross-browser incompatibilities, It is still better to do it in pure Js. Because, most people who use jQuery for simple task as that, fail to even understand what an HTTPRequest Object is about. I only recommend people to use frameworks, once, they have an idea, how things are working behinds the scenes. Now, having said that, with the PdoNoodle, I guess I was merely trying to show an easier way to get around of writing 6+ lines of codes by using just 1. Also, there are newbies who tend to not try PDO, because it somehow seems harder than mysql for them.

    Now, what I have learned is to extend the PDO class, to limit the number of methods to one, instead of $foo->()->();
    I will try to implement those and other feedbacks given.
     
    eritrea1, Oct 9, 2013 IP
  19. #19
    There are even more reasons to do that too -- it's like using extra variables when you don't have to, or performing the same calculation more than once...

    Every time you call a method or function, most languages (even machine language) have to put a 'return address' on a 'stack'... any values you pass (in the case of a method, the parent class is itself a value in most cases in the form of a pointer) also end up being passed on the 'stack' -- this increases the memory footprint and adds the overhead of garbage collection on exit to your code. It's why for simple short routines unless you are trying to isolate scope, it is often better to type it out instead of passing more values and data between functions and methods. This is REALLY true on anything that's going to be short operations, or things that you can do with one function/method instead of two or three.

    By switching to a single method instead of performing a method on the result, you decrease the memory footprint and execution overhead. The only time to split them is when you might have multiple different operations on the result -- PDO and PDOStatement are a great example of when it makes sense to have them separate.
     
    deathshadow, Oct 9, 2013 IP
    eritrea1 likes this.
  20. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,630
    Likes Received:
    724
    Best Answers:
    152
    Trophy Points:
    470
    #20
    Uhm. How would you code a coordination webpage for timesheets? If I may ask? Rearranging the people who's signed up, placing them on other shifts, removing given users from certain days, etc. Unless you're gonna code this in an actual programming language, to create an actual working program (which probably won't be able to go online or being used via a web-browser), I don't really see how coordinating people across different venues and times and dates gonna be any easier than "click here, drag there".

    As for "talking to the database" - it sort of has to, to update said dates, venues etc.? Clients tend to have to actually "talk to" the database, both for retrieving, and for writing new content...

    Accessibility is not crap - but then, this IS an in-house management app for workers and users, and not something we can't control who's accessing. I'm assuming you're thinking about accessibility if someone turns of js, for instance - that's a non-issue here. Neither is text-to-speech a problem, nor obtuse browsers. All that helps, of course.

    As for the amount of data you're serving... 100MB lines at a minimum, I don't really care if the codebase is 100bytes or a 100kilobytes. If I run any type of speed-test, say YSlow, on the page, it returns with all A's, and a pageload of about half a second pr. page at the most. I don't really think anyone is gonna complain about that. Given that most of the pages uses Ajax-calls against the database, users aren't gonna see much pageloads anyway, since the actual work is being done behind the scenes.

    Could I've reduced the number of lines in the js-file by using plain js, instead of jQuery? Maybe. I'm not sure I could. Minified jQuery isn't that heavy, and by placing all the js-files into one single file, you avoid the problems with multiple requests.

    As for overall size, my actual code is about 80kB - my CSS-file is 92kB and JS (currently) is about 250kB. That's a total of 350kB (approx). Given that not all of this is loaded on every page-visit, or pageload, I'm guessing (haven't done a load-test yet) that the average page-load is hitting 150kB. Add to that content from the database, and I'm not even utilizing 1Mb/s load. Which is nothing, whatsoever. If you also factor in that this is maybe gonna be used by max 20 concurrent users, there isn't really that big a deal for cutting more bits of code off. The CSS and the JS is of course gonna get a make-over before release, since there is quite a few properties and functions not needed in there, but that'll save perhaps 100kB total at the most.
     
    PoPSiCLe, Oct 10, 2013 IP