Hi!
[quoteI really don't see why it is not possible to have, i.e., two possible places to emit JS code - one in the head (for stuff which needs to be placed there), one for anything else at the bottom of the page, right after jquery, and instruct any part of S9y which emits JS (can't be that many so far) to put their JS there? (Apart from the fact that plugins need to be rewritten to work with that method, of course. Yes, I
am aware that there might be [good] reasons I, being the frontend-only guy here, simply don't see or understand.)[/quote]
That's the problem, because basically everywhere where HTML can be emitted, Javascript can be emitted. So we can't really control where JS is emitted and where not. and I wouldn't really want to force people putting JS only at specific places - that's against the "flexibility" concern that Serendipity puts quite high. JS actually is allowed everywhrere, why should we as a CMS forbid it suddenly?
I don't think the performance remedies the loss of flexibility...
garvinhicking wrote:Which ones? Wordpress has it in the head...
That part was referring to losing inline CSS and JS as far as possible, not where to include external JS files.
Ah, of course okay. I'm all for having as little as possibl einline JS and CSS; wherever we currently do that, if there's a solution to NOT do it adn the solution does not affect flexibility, I'm all for it.
I really don't see why including it in the head should be related to it being our JS library of choice?
Because then, every plugin and template author can ALWAYS use $(...) without needing to fiddle "hey, can I do that, jquery is not even loaded yet".
Are you gonna use the same argument once we get to rewriting the backend template or getting a new default template? Because the old ones work "perfectly fine" as well. (As a matter of fact, they really don't.)
My only argument really is, not to put boundaries on people and make it as forward-compatible as possible; having JS it in the head is very forward compatible, while at the bottom of a page is not (due to scoping).
Also, I hate revinventing a wheel. I don't see much reason to tear down a complete building just to build a new one on top of it that, just because you wanted to change the heating inside the building. We are a small project and need to build on working foundations. Of course we need to be progressive, but not by sacrificing flexibility or breaking existing stuff without any benefit other than that.
Actually I don't think we'll face any problems with that, and I fully believe that we can have progress, but still preserving our strengths that everything can be done with our framework.
About Isotopps performance problems: Those mostly arise to due many people reading his blog "statically", while s9y's core is built for dynamic features. Isotopp really doesn't use much of the dynamic functions, and s9y indeed lacks a good "statification" approach. I did work on some cachesimple plugin enhancements, but without participating developers in this area I don't think there'll be a good solution. I'm not even sure if there is a solution to the problem, because it's inherent to s9y's flexible plugin API approach that would need to be "removed".
Don: Yes, I want jquery as fast as possible because it's prime-time ready. And for large changes in 2.0 this would mean that 2.0 might take a longer time. Ideally I'd like 1.6 to happen a lot sooner, and also give users some feasible new features before 2.0
Regards,
Garvin
)
Or maybe I am in the process of forgetting it.