jquery vs mootools: my initial thoughts
Introduction
I’ve been using jQuery regularly for my new job now for about 3 weeks or so. I’ve used the selectors, event handling, short cuts/handlers, animations, plugins etc. Nothing too fancy, but in general, a descent exposure. I’d like to compare it with Mootools. And while I do rock a Mootools skin on my phone, I’m going to try and remain as objective as subjectively possible. I’m going to try and stay positive about the differences and give use-cases for using either.
Gut Reaction
jQuery is fast to learn, easy to use, and passes the ‘thinking’ to the framework. It allows you to do incredibly powerful client side stuff without knowing too much of the inner workings, worrying about being specific and explicit about your syntax or organization, and most importantly lets you get this stuff done quickly.
Mootools on the other hand requires you to be explicit. You want to create a node with 4 children and easy of them have a bunch of inline attributes? Cool, do it manually, instead of specifying a string of html which the engine will parse and DOM-inize for you (jQuery can do this). Most prominent for me: jQuery is very smart and very easy to use, but lacks a certain elegance due it’s lack of explicit control; Mootools requires more work and overhead to get something done, but is very organized and beyond the learning curve, more meaningful.
Example
To create a series of nodes in jQuery, it’s as easy as this:
var html = ‘<div id=”div-one”><span id=”span-one”>yo yo</span></div>’;
$(html).prependTo($(’#random-node’));
In Moo, it’d be something like this:
var first = new Element(’div’,{’id’:'div-one’});
var two = new Element(’span’,{’id’:’span-one’});
first.adopt(two);
$(’body’).shift().adopt(first);
One is easier/more implicit than the other. However the other is much more explicit, and easier to follow for a foreigner who isn’t too familiar with the jQuery syntax, rules and behaviors.
Optimization/Speed
I don’t know too much about jQuery’s speed. I believe that at this point we’ve got to the point where an extra 10 milliseconds isn’t a do or die or decision maker for what framework/library to use. But with that in mind, one of the great things for Moo is the ability to compartmentalize only what is needed for client side behavior. Everything is kept as a separate stand alone, window based class, where as jQuery seems to throw in a lot of other code into one batch which is mutually dependent.
This goes back to my gut reaction though. For a new comer, I don’t want to try to determine what classes/objects I’ll need. I want a script tag that has almost everything that I need. No playing with downloader apps to pick and choose what my project will need. Mootools therefore introduces a higher level of (initial) complexity, but brings with it greater than control, and again, explicitness.
Community
Up until this point, I’ve more or less tried giving opinions for and against both libraries, but in this category (Community), there is a winner hands down: jQuery. I don’t really know what the reason for this is. I would say that jQuery has been more organized in their community/developer evangelism, which is completely true, but I don’t think that’s the real reason.
While Mootools is still trying to get it’s community plugin system up and rung (MooForge, I believe), I think a core reason it’s the direct and simplicity of jQuery. I think it was able to garner such a strong following because the barrier to entry is to incredibly tiny. I don’t need to understand JavaScript syntax, programming syntax, or the inner workings of client side development. The very syntax that I love about Moo (e.g. new Element(’div’).addClass(’oliver’).addEvent….) is also probably what turns people off. The fact that I need to be so direct about what I want done is something that many people probably don’t want to deal with.
Conclusion
But away from my tangent, the jQuery community is amazing. So many plugins, organized horizontally and vertically by jQuery themselves. So many resources to learn the syntax, deconstruct plugins to understand the code, etc. While my obsessive compulsiveness when it comes to coding syntax and practices would never allow me to fully embrace and adopt jQuery personally and independently of where I work full time, I can understand fully it’s benefits. I’ll always evangelize Mootools whenever I can, but after this exposure to jQuery, I’ll understand where it’s most useful and for whom Mootools would really be welcome to.
grabbing an attribute in mootools: .[name] or .get or .retrieve or .getProperty?
Something I ran into just now was returning an anchor’s attribute consistently across browsers. So I have an anchor with an address like ‘/users/delete/5/’ which does what you’d think it does. But I ran into an inconsistent return response in (you guessed it) ie6. In all fairness, it might not be IE6’s fault, but it speaks more to a problem with mootools. While it is a nearly perfect library/framework, this does bug me.
Mootools has 3 native methods for accessing an attribute/property for a node (which in the DOM, often overlaps). .get(’name’), .retrieve(’name’), and getProperty(’name’). While they are all meant to do things a little differently (eg. set an attribute for a node, store a data object in an existing object (which could be a DOM node) or store a property in an object (which again, could be a DOM node), they seem to overlap a lot.
So I have this anchor, and when I tried accessing it (grabbing the href) using the accessors I have, here at the results for FF (mac) vs. IE6 (windows):
.[name]
FF: full path including host
IE6: full path including host
.get
FF: request path (excluding host)
IE6: full path including host
.retrieve
FF: null
IE6: null
.getProperty
FF: request path (excluding host)
IE6: full path including host
Now it’s hard to say what is the correct expectation. I’m sure I could figure it out in the eyes of the W3C, but rather, here’s what I’ve noticed. Both browsers take whatever path is specified and render it internally with the host. I understand this since it’s what the browser would need to actually make a full request.
The 2nd and 4th accessors, though, are inconsistent and cause problems since their expected results different. IE6 includes the full path & host each time which is most likely an issue with how it accesses it. When the browser defines the href in memory it must overwrite the local pointer which then can’t be accessed properly.
So what do I do about this? Nothing really. I have this documented now so that if there is a pre-dom-ready source that I need to inspect (for example, href values written but no rendered after the dom has been loaded), I should be using the .[name] accessor, and make adjustments accordingly based on what is being accessed (in this case the href which has the host prepended).
These differences really suck since they introduce inconsistencies in places where you wouldn’t expect them and thus break applications/scripts (like what drove me to discover this). I would hope a framework/library would help mitigate this kind of thing, but alas, they can’t do everything, and I’m just happy for what they do bring to the table.
IE6 and input type changes: short answer, ie6 sucks, long answer:
The Problem
I ran into another problem the other day native to ie6 (well ie7 and ie8 too, to be fair) where by I was trying to dynamically change a text input field from type=”text” to type=”password”. Safari, chrome and firefox had no issues. It was a simple as node.type = ‘password’, or since I was using mootools, node.set(’type’,'password’). Resolved. But wait…
Then I ran into IE6, whereby I got a nice “This command is not supported.”. It took me a while to figure this out. At first I thought the node didn’t have mootools ’set’ method for some reason (didn’t access it right?), but once I found out the reason, I looked for workarounds. None really. Other resolutions that attempted completely different code, but no workaround for IE6 specific to change the type. It seemed microsoft had decided that an input field’s type should not be able to change after it’d been loaded. I’ll get to that in a second
My Resolution
Spit out password fields on the page for when it gets sent back to the client. When the DOM has loaded, iterate over the input[type=password] fields (I did this via the mootools selector node.getElements(’input[type=password’)), make them hidden (via add a class or adjusting it’s style property), and make a new node that has an input type with the text value. I added the same classes to it as the password node had. When a user focused on the field (the text one that was originally a password field), I destroyed it, and removed the hidden class.
What really bothered me
“This is an expected behavior. One can’t change the type of an INPUT element once it is already created and became part of the DOM. The behavior is documented below in the Remarsk Section:”
That was microsoft’s response in their developer forums. That was last year, and instead of addressing it as an issue and complying with a standard, they were stubborn and basically refuted the claim as a bug. I’m not sure how I feel about the standard. I understand why an input type is set after the DOM has been loaded. I can’t change a tag type from div to span after the fact (or at least I shouldn’t be able to). Ideally, in my own head that is, every input type should have a separate tag value. <button />, <select />, <file />, <text />, <textarea /> and <password />. I think that’d be ideal, and save a lot of confusion.
Either way, that’s my resolution. M$ response is kind of sucky, but what can ya do.
Flexibility: Server side vs Client side
I’ve been told by many people, veterans in their respective industries such as family friends, family members, etc., that when you’re in a technical field, the best type of job security is to specialize. I imagine this would extend to a lot of different areas (entertainment, finance, management, etc.) but especially in the technical/programming arena, I find it’s very true and productive.
What I mean by this is, be very very very good in a very very very specific field/discipline. Be the best out of all the people you know. If you’re a server side developer, don’t try and learn all the server side languages; rather be the best object-oriented php5 developer who knows the ins and outs of PECL and PEAR extensions. Or be the best db admin who can optimize an InnoDB mysql engine better than anyone you’ve met. That way, when anyone is looking for something specific, you’ll be the first person to come to mind.
I’m too obsessive to follow this though. I would hate being really good at one thing, and then just having to depend on someone else to help me out with the other. Because of that, I’m not very very very good in one area, rather I’m pretty good in a bunch of them. But this is actually still making me fall into a very specific niche; namely, if someone is looking for one guy who can configure a linux/apache box, set up and admin a db, set up a server side dev env., do designs in photoshop, turn them into html/css/js, and add in ajax/js techniques to make a more interactive application/website, I’m that guy. If I were to work in a company with other developers, I probably wouldn’t be better than anyone in any specific area. I wouldn’t be the best JS guy, or CSS guy, or DB guy, and because of that I’m probably not suited for a lot of companies, but for my current contract, they needed one guy who can wear 5 or 6 different hats.
So ironically, the fact that I don’t specialize in one specific area, rather 5 or 6 of them, makes me specialized. It makes me the specific person to go to when you need one person who is pretty good in a bunch of areas.
If you read the title, you might wonder what this has to do with it; it’s a segway into my point. On my current project, I’m having to do both client and server side dev., and it’s making me realize something. The server is way more flexible than the client.
—
Here’s why.
—
The server is usually a linux/unix box. It’s role in a web application/site is to fulfill client side requests, push out data, yadda yadda. It normally doesn’t do anything visual. The client, however, is intrinsically visual. It’s supposed to represent a server architecture in a cohesive, logical way. Now when doing client side dev., you have to normally worry about ie6, ie7, ie8, ff3, sf, opera and chrome (not always this, but thats the goal). At times you’ll run into things you can’t do in the others (CSS3, certain types of ajax callbacks, etc.); sometimes they’ll be things that aren’t worth the time, but other times, it just can’t be done. There is no hack or way around it, it just can’t be done. It’s frustrating to say the least, but it’s making me really value and respect the entire web paradigm and the server’s role in it all.
—
How does this relate to my introduction?
—
I find that there is a lot of ego involved in the web industry. A lot of butting heads in terms of how important people/disciplines are in the grand schemes of things. There are the executives/bus.dev. guys, marketing dudes/gals, client side developers, server side developers, operations/db dudes, and creative/design people. That’s generally how I break it down, and with some exceptions, everyone thinks their role is one of the most important ones. They’ll pretend and put on a face that they don’t believe it, but at their core, there is a lot of pretense about their own positions. I suppose that’s normal considering that’s their professional role.
I’ve always maintained (and have a post that should be coming soon) that one of the most important roles, which I’m terrible at and in no way consider myself part of, is in fact the creative/design ones. I’ll leave my reasoning here for another post. My understanding of the flexibility of client vs server side therefore comes from the fact that I don’t specialize in any one area. If I were a operations/db guy, I’d think the db was the most flexible. If I was a pure server side guy, I’d think it was the most flexible, and the same for the client side.
The point I tried to make with my introduction and the conclusion of the server side being the most flexible is that because of my lack of specialization (and therefore abstract specialization) in the full life cycle of a web application, I think I’m in a unique situation to make that judgment. It’s not right or infallible or anything, but I come at it from a unique perspective. My career/financial stability doesn’t hinge on any one area of the cycle. I could find a job doing client side, or server side, or db/operations, maybe even some mild graphic/creative design stuff. Even as far as more on the management and marketing stance, I think I’d be alright. And because of this, I think I’m in a convenient location to sit back, analyze where any bottle necks are in flexibility, and make a call on what makes the most sense and is most accommodating.
And my conclusion? The server side is way more flexible. There is never a point/time when I can’t do something. It might take more time than I’d hope, require more resources (memory, developers, etc.), but at no point do I have to create ‘hacks’. It’s logical and follows procedures and standards. I think this is mainly because it’s been around longer. The server side env. is really just a programming environment. It’s been around, and perfected, since the 50’s. The web client-side has been around, for the most part, for less than 15 years.
That being said, the client side is getting better. With Flash, Adobe Air, Google Gears, and some really cool plugins (Rhino, for one) the client side is trying real hard, and milding succeeding, in become less of a bottle neck for an application. I think with time it will succeed, but as it stands right now, the server side is where it’s at. Fewer headaches, and more logic, make it one of the most time-satisfying parts of the projects I’m doing lately.
Jumping the gun: html5/css3 is not here yet!
On Twitter, I follow a bunch of people in the development arena. JavaScript framework core developers, designers, mysql/php architects, etc. etc. I’d say about 50% of the people I follow are in that arena (the other 50% probably being aggregators or tech news sites/blogs).
A consistent theme I’m finding in the past few months has been css3/html5 posts. They talk about new effects, rules, possibilities, etc. etc. Now I try to be optimistic about web development; I try to practice valid w3c content, semantic markup, everywhere I can. But the age of css3/html5, at least for me, is still so far off. 25% (at the least) of internet users are still using ie6, another 40% are using ie7; that takes us to about 65% of internet users using subpar browsers (ie7 is a step up, but still very much sub-par) that don’t support anything close to css3 and html5.
These browsers are so terrible that I spend about 80% of my client side development time focused on fixing issues I run into there. I write code that is semantic, valid, and based on standards, and then debug it and add in browser-specific fixes for them. Now the reason for bringing up my (and obviously most client side developer’s) hatred for it is because of this sudden (last 4-6 months) pushed towards css3, but even more, html5. Put simply, we’re jumping the gun.
We’re not anywhere near the period of time whereby these standards can be used properly for the vast majority of users. Yes, graceful degradation and progressive enhancement do allow us to make use of them for those vendors that have supplied standards-based browsers, but the time being, maybe only 25-35% of users will get to experience these enhancements. So why put so much effort into transforming your sites and communities to use these standards? Is it worth it?
HTML5 is, believe-it-or-not, a pretty large step forward. While it’s simply an extension of html 4 and more than anything, introduces some different namespaces and tags, I keep coming back to thinking whether we should bother with it right now. It won’t be until IE9 or an IE8 service pack/update that the majority of users will get any use out of it, and for large companies and communities, it represents hundreds/thousands of hours of work, changing your design/style guides, and means often times having multiple code/script bases for different browsers that represent which support html5, and which don’t.
Now I’m coming at this from a freelance/contract developer. I have a task, and it’s in my best interest to make it work in the top 3 browsers (ie6, ie7, ff3) as fast as possible, and as cleanly (the fewer moving parts, the better). I might use some css3, I might use some transparent png’s, but that’s my limit. Going over board with css3 and integrating html5 is not a priority of mine, and would represent extra hours which I couldn’t work into my pricing/rates. I would rather spend my time writing semantic, standards based code, and open sourcing anything and everything I could to help out others; at least until one of the top two browsers supports html5 (ff isn’t there yet, despite many claims that it’s the number 2 browser next to ie7).
This approach by me has it’s problems. Namely, if people don’t push technologies that aren’t yet wide spread, than the major vendors won’t feel as pressured to support them. I understand this, and in many ways, it’s up to the big guys to help push new technologies. But this brings me back to the post’s title. Are we jumping the gun? We’re years away from a top two browser from supporting either css3/html5. So should we spend all this effort, time and money developing for something that most user’s won’t even experience?
There are exceptions to this; if I’m designing an app/site for an intranet where I can control the browser type. Or if it’s for a specific niche (eg. graphic designers, web developers) where I can safely assume or pressure the visitor to use a new-age browser (safari, chrome, ff3). Then maybe I’ll take the time to learn the new semantics, make the site pop like it never could. I’ll spend the extra time, effort and money to create a richer experience. But these are exceptions, not the rules.
These are thoughts/ramblings that have been going through my head for quite some time now. They aren’t polished, they aren’t definite, but they are something that I’ve thought of, and I assume other’s in the community have as well.
While these are my thoughts, and I’ll stick by them for a while, I won’t stop trying to learn about the new technologies. Progressive enhancement, ajax, json, jsonp, and whatever else comes along, I’ll jump into, just like css3/html5, but just like ajax didn’t become popular until XHR became widespread in most browsers, I won’t make use of it (with certain exceptions) until major vendors (m$) decide to give me the tools to do so.
Progressive enhancement
I was in an interviewing not too long ago for a company with a terrible terrible idea, with easily the most terrible team leader I’ve ever had the misfortune of speaking with in a professional context, when someone in the interview asked me about ‘Progressive Enhancement’.
I didn’t know what the term meant, and when he explained it to me, it made logical sense; it’s something that I’ve been doing for years, but I just never knew the formal name of it.
In a nut shell, progressive enhancement is a way of developing and designing a web experience to be optimal for the viewer. It’s a very general term/description, but it’s because it can be used in many different areas. For example, CSS is intself a progressive enhancement technique. The reason I say that is that when Google indexes your site, they don’t see CSS, they don’t see much layout; they just see a bunch of text, code and tags that they give importance to.
However, imagine now your friend checked out that site; if they viewed it the way google does, they wouldn’t be able to use it much (the internet of the early 90’s was like this). CSS came along and was designed to lift/boost the visual experience of a visitor that wasn’t a robot, and that could understand visual context.
But that’s the most general case, two that I’ve been doing lately include CSS3 graceful degradation, and ajax based hash-requests (my own term that I just though of now). CSS3 degradation is what it sounds like. I throw in a bunch of CSS3 for browsers like IE8, Safari 4, FF 3.5, that makes the user interface spark and work better. For the others, they aren’t affected, so nothing bad happens.
This one is common place, and has been for a while, but something that’s really cool and super effective (something Digg should’ve done for their digg bar url fiasco, which I can safely say as a backseat-driver), is anchor link experience degradation (another term I’ve coined now, and is linked to that above). Basically, all these anchor’s have href values that point to another page/experience right? Well using some not so fancy javascript, you can override the default behavior for browser that support javascript (eg. not google bots), to change the experience.
So for example, I’ve got a link on my homepage that points to my profile link yadda right? Google bot is going to hit this, visit that page, index it, and keep on moving. A user would normally do the same, but using progressive enhancement, I can make the experience so much better. I can make it so that when they hit the link, I capture the event, prevent it from happening, and instead take the href value and make an ajax call to the same url. My server is configured to notice that this is an ajax call for the profile page, and returns the contents of that page (or view) in a json object. I then only replace the part of the page that would be different for the profile. This prevents a full browser resource re-load (Eg. headers, footers, assets etc., don’t get loaded/requested again).
Now this isn’t just the core of what Ajax is about; ajax is about enhancing the user experience to prevent unnecessary loads. This is about changing the entire experience, all-together, to make your site completely ajax driven, bookmark-able (via url’s like website.com/#/users/onassar/profile/), navigation-able (made that up) through the forward/back links, and faster. It takes a lot of work both on the server and client side, but changes the entire scope of your application/site. But because you’re using progressive enhancement, you’re keeping google happy with new links for it to index (not like flash), and making two versions of your site; an ajax one which is faster, and a regular synchronous one which can be used for old school browsers.
This technique has always been buried into everything I’ve done on the client side, and while I didn’t know the name (and to be honest, as long as you’re implementing it the name shouldn’t/doesn’t matter), it’s something I’d really push for wherever possible. This has a lot to do with some more abstract concepts such as REST-ful resources/requests, but at the heart of it, it’s about improving the user experience to the highest capacity, and degrading gracefully when it won’t work.
Regarding the digg fiasco; basically, a bunch of people complained originally that when digg changed all the anchor url’s to point to their digg bar which pushed out a link in a frame, that they were losing SEO juice. Now which google could get pissed by this, a fairly straight forward, progressive enhancement technique couldn’t been to write out links like this:
yadda
Google would visit, and move on through to the page, passing along the ‘yadda’ seo juice. But then adding in some nice client side JS (weird that I have to say that, since there are not server side js ports), I could prevent the default action of that anchor, and redirect the url to digg.com/[REL VALUE].
This would keep the juice flowing, and improve the experience by redirecting to the digg bar url. While I’m sure they thought of this (super smart dudes over there), and maybe they ran into a google/search engine blacklisting situation since they were in fact leading google to a different experience than is intended for the real visitor, I would’ve been curious to see how bad the upset would’ve been.
Dynamic Variables Assignment?
In JS, I ran into a problem where I needed to create a shortcut string, and then turn that string’s value into a reference to a different object.
So for example, I create a string called ‘oliver’ under the variable shortcut like so:
var shortcut = 'oliver';
Then I have a bunch of other code in my framework, and to access any of it, I would write something like:
FRAMEWORK.doSomething();
I wanted the framework’s name space to be preserved (so that I could easily upgrade/update it without affecting any code), but I wanted to be able to use my shortcut handle to access the framework, such that writing the following would work as well:
oliver.doSomething();
This led me to the use of eval to run a js command in js itself to get the assignment/reference working properly like so:
eval(shortcut+' = FRAMEWORK');
This worked really well and met exactly what I was trying to do, but I’m always hesitant to use eval. I’ve heard terrible things about it’s security and performance (although most ajax is based on this function). I’ll look into it and update the post if I find anything, but for the mean while, this has helped me do what I was trying to. It allows me to write really general client side framework code that can then be extended easily into a new namespace without any conflicts. Very powerful stuff.
When I search for it on google, it didn’t come up right away. My search terms (hopefully writing this in the post will help someone else) were: dynamic javascript variable assignment.
ps. The picture is supposed to represent a ’shortcut’. not the best fit I don’t mind saying.
Update: window[name] = reference is the winner. I don’t know why it escaped me before. This should prevent the use of eval and will allow you to dynamically create variables in the window scope.
Mootools caveat #2: noCache in new Request() is your friend
Reading the docs is really worth it’s weight in gold. Namely, noCache option/parameter for a new Request (aka. Ajax for mootools) object really does make all the difference in the world.
“noCache – (boolean; defaults to false) If true, appends a unique noCache value to the request to prevent caching. (IE has a bad habit of caching ajax request values. Including this script and setting the noCache value to true will prevent it from caching. The server should ignore the noCache value.)”
I was having a problem with ajax being ‘retrieved’ by IE, but not actually making a hit in my access log. I was baffled, and figured it was a caching issue, but confused since safari/FF were working fine.
For those of you out there, be aware of this. My specific problem was actually based on a call to something like:
http://www.website.com/controller/action/
Now I can make that exact url call and have it return a bunch of html; but for the framework I’m working in, adding a header of AC:true (short form for ‘Ajax Call’) will change the output (namely, to a JSON object instead of pure html). It seems IE was caching the request since the page had been requested without the header, and then returning it every time.
Damn you IE!!!!! I understand <link /> and <script /> and <img />’s being cached, but XHR’s? Come on. They’re based on actions (eg. click events, mouse overs, key combinations), not default behaviors of a page load (ordinarily).
Mootools caveat: event.target is not extended by $
This took me wayt too long to discover:
When using event.target via mootools event handlers, I figured out, after way too much testing, that event.target is NOT extended via $, and therefore doesn’t have accessors like .get(’tag’) and default’s for the $ (dollar sign extension).
I wasn’t sure if this was note worthy of a post, but I reckon I’ll fill this up with enough keywords that it’ll hopefully show up in the SERP’s for mootools event trigger target source, etc.
We shall see.
Script/Asset abuse: this is getting ridiculous!
Frameworks like YUI, JQuery, Mootools, Dojo, etc., are arguably the best thing to have happened to JavaScript in 10 years. I remember when I first learned about their existence. I was coding my own animation script (functional, not OO, and definitely not efficient) that didn’t do anything fancy; just scrolled up and down. I remember then hearing about dojo, and thinking I’d wasted so much time.
Then what I did, was go around to all the different frameworks. I don’t even think JQuery existed in it’s current incarnation at that point (December of 2005), and I looked around at as many as I could (dojo, mootools, and a few others that have since become relics). This post though, isn’t about the greatness of these frameworks; rather it’s about the terrible abuse.
With any new technology, there will be people who embrace it for ease of use and creating a new standard, and then there will be those who completely abuse it. The screen shot below is a perfect example of that (click it for the full size):
If you can’t see what I have a problem with, then you need to leave this post right now. For everyone else, this is an absolute joke. This is for a travel promotion site called StudentCity. My count of javascript assets: 20 (excluding any dynamically load ajax/jsonp requests). My count of css assets: 11.
These tallies were retrieved via after the DOM had been rendered, so they may not match up perfectly with the source, but I assure you they’re accurate.
If you visit this site, you’re not going to notice too much. A few swfs, a bit of animation, and a few non-css related hover effects. In no way, should this account for the number of requests for just js/css assets. It doesn’t make sense, and is terrible programming/development. I understand that in many projects, control is sometimes non-existent. You need to conform to someone elses demands, some other developers tendencies, or some other designers inexperience. But for the firm who developed this site, if anyone had taken a look at the source after it had been finished, a huge red flag should have gone up.
Concatenating files is easy; minimizing requests is easy, and a faster client side render time will actually make you money, for a relatively low cost (maybe 2 hours). This speaks to what frameworks are doing these days.
JS frameworks, and even php/server side ones like CakePHP and CodeIgniter (ones I’m working with now) are leading to a generation of websites and applications that were developed by people who have very little idea what they’re doing. I don’t think it’s much different than the age of Frontpage/Dreamweaver/GoLive developed sites, but it’s certainly not something that you should be paying for it you’re working with a development firm. It’s annoying as a developer to see this, and probably a do-or-die thing if I were to be working with or hiring another developer to work with me.