Subtle changes, bugs and feedback

Thanks V. It's nice to know that the LFGSS gods listen to it's people and take note of requests for improvements and ideas to shape it's future.

Best. Forum. Day. EVAR!

HTML Templates in the database: 1,131

This makes me glad the last CMS I built a theme for was Drupal, you hero!

oh BQ, you crack me up.

jQuery is a tool, Zepto is better if you're going to faff about filesize etc. So I guess you're be really offended by CoffeeScript then, as it compiles to lint passable javascript, which is slightly large in filesize, but guaranteed to work on everything, not more Array.indexOf prototypal injection for IE, etc etc? CoffeeScript it also beautiful to write. But then, it's new fangled, so fuck it.

oops... just gave VB 8x rep because the rep box wouldn't disappear so I just kept clicking!

oh BQ, you crack me up.

jQuery is a tool, Zepto is better if you're going to faff about filesize etc. So I guess you're be really offended by CoffeeScript then, as it compiles to lint passable javascript, which is slightly large in filesize, but guaranteed to work on everything, not more Array.indexOf prototypal injection for IE, etc etc? CoffeeScript it also beautiful to write. But then, it's new fangled, so fuck it.

Don't see the point of CoffeeScript. It's not that much quicker than just writing the actual JS.
Aside from the issue of leaving your code optimisation to someone else in the first place, CoffeeScript pumps out some pretty inefficient code - functions defined as variables, functions inside of object literals, switch statements, etc. which will use more memory and perform more slowly.

Zepto is utterly irrelevant to me because it doesn't support IE, and sadly I have yet to have a single client say "neither do we". As such there's no point me even finding out what it does.

The whole "guaranteed to work on everything" thing - what exactly is wrong with including an array.indexOf for IE - it's small, efficient and leaves all grown up browsers to use their native implementations, and crucially you only include it if you know you will need it, rather than shoving it, and a load of other things, in whether or not you do.

I would imagine you take great care to optimise images, reduce server fetches by using sprites or maybe base64 inline images. Why go to that trouble if you are then going to lard up the page weight again by throwing in a load of JS, HTML and CSS that you know you will never need?

Which is why I get frustrated with you, you appear not to comprehend the size and complexity of a decade old codebase used to power 20,000 web-sites, that I then customised with the addition of at least 20k to 30k of my lines of PHP, and another hundred HTML templates.

No need to get frustrated. I comprehend it well enough.
I've had similar issues with Community Server. I am only too aware how much you are going down the rabbit hole when you embark upon such a task.

Just pointing out where the biggest savings potentially are. I know it may not be possible to achieve them.

My offer of help is genuine, by the way.

It is an option.

Go into your browser settings, and change the font for sans-serif to comic sans.

Sweet

http://static.lfgss.com/attachments/49762d1329811964-screen-shot-2012-02-21-at-08.11.55.png

1 Attachment

Oh, that's awesome.

Might actually have to make that change one day.

It's really not as bad as I thought it would be.

April 1st isn't that far away.

Ha, BQ, you continue to crack me up!

Coffeescript is way faster to code, especially if you're building huge applications. And the code it produces is way more efficient. named functions (what you call "functions assigned to variables") are way more efficient than anonymous functions lying about all over the place, they create memory leaks and clog up the GC. It encapsulates your code in closures automatically to stop global namespace clutter/conflicts. If you work with some really good JS developers, you'd understand all this.

Anyway, I can't be bothered trying to explain it to you. #overyourhead

Now, how do you feel about SASS/LESS/Compass?

I'm a great fan of LESS (I know you weren't asking me).

I can't wait to get off of this legacy code base and start doing things the way I feel that they should be done. I'll reevaluate the landscape of CSS compilation tools in a few months time when I get to the front end, but today if pushed: I'd say I'd go with LESS.

Don't see the point of CoffeeScript. It's not that much quicker than just writing the actual JS.
Aside from the issue of leaving your code optimisation to someone else in the first place, CoffeeScript pumps out some pretty inefficient code - functions defined as variables, functions inside of object literals, switch statements, etc. which will use more memory and perform more slowly.[QUOTE]

Wrong.

[QUOTE]Zepto is utterly irrelevant to me because it doesn't support IE, and sadly I have yet to have a single client say "neither do we". As such there's no point me even finding out what it does.

Fair enough if you have to support IE

The whole "guaranteed to work on everything" thing - what exactly is wrong with including an array.indexOf for IE - it's small, efficient and leaves all grown up browsers to use their native implementations, and crucially you only include it if you know you will need it, rather than shoving it, and a load of other things, in whether or not you do.

CoffeeScript only includes what you need. Maybe you should actually read about it!

I would imagine you take great care to optimise images, reduce server fetches by using sprites or maybe base64 inline images. Why go to that trouble if you are then going to lard up the page weight again by throwing in a load of JS, HTML and CSS that you know you will never need?

Because the CSS reset is gzipped to almost fuck all, and for the applications I'm building, the reset reduces the size of the rest of the CSS. The JavaScript it almost almost always uglified or Closure Compiled, so is also tiny. And I only include what I need.

David, I've been working for 2 months in SASS, and I think it's better and more flexible than LESS. Better variable access, better mixins etc etc

Two bald men arguing over a code.

Still serif fonts in the text input box in Firefox. :(

Nerrrrdddds

named functions (what you call "functions assigned to variables") are way more efficient than anonymous functions lying about all over the place, they create memory leaks and clog up the GC.

But they are way less efficient than the old
function name(vars) { }
syntax

And functions inside object literals are orders of magnitude less efficient than functions defined as prototypes of objects.

If you work with some really good JS developers, you'd understand all this.
#overyourhead

I'm glad I continue to provide amusement.

As I understand it

var doBar = function (index, element){....};
jQuery('.foo').each(doBar);

is more efficient than

jQuery('.foo').each(function (index, element){....});

because of compilation, scope and other things I never bothered to understand.

@Velocio
If we're doing better font sizing, are scalable icons on the roadmap?

yes, because in the first instance you are creating the function once and executing it lots of times, whereas in the second you are creating a new function lots of times.

I can do excel macros

Sassless CSS aside, I've got a little bug to report - apologies if it's already been covered, and it isn't really a biggie.

If I hit "Today's Posts", and then try and scale the text using the brand new text-resizer, the page reloads with the ?fontsize=1 suffix, but loses the searchid, so I end up with http://www.lfgss.com/search.php?fontsize=1, rather than http://www.lfgss.com/search.php?searchid=12358533&fontsize=1

Mac OS 10.7.3, Chrome 17.0.963.46, fwiw (although it's prolly not a browser/os specific issue)

/attachments/49766

Small pic. Click on it and make it grow.

1 Attachment

Still serif fonts in the text input box in Firefox. :(

I'll look at it this morning, but if it's not effortlessly fixable I'm going to skip it.

If we're doing better font sizing, are scalable icons on the roadmap?

No.

Better than scalable icons would be sprites or SVG.

But I'm not doing those either.

This is where the bleed into legacy app would entangle me too greatly. A lot of the icons aren't even in the HTML templates, or rather, part of the image file names come out of PHP as variables, and are stitched together at runtime and then construct file names and paths within the templates and end up pointing to gif files.

I could in theory just replace the entire icon set with a similarly sized set of png files, but even then I'm not convinced I would find every trace of the word "gif" in the codebase.

You've got to bear in mind the code base is split between those 2k PHP files and the 1k templates in a database... and because it's PHP it's been abused slightly so a lot happens in eval() at runtime.

It's actually kinda neat that I've managed to butcher vBulletin this far... I'm still using over 90% of the existing vBulletin code. Even though from outward appearances you wouldn't guess it.

Sassless CSS aside, I've got a little bug to report - apologies if it's already been covered, and it isn't really a biggie.

If I hit "Today's Posts", and then try and scale the text using the brand new text-resizer, the page reloads with the ?fontsize=1 suffix, but loses the searchid, so I end up with http://www.lfgss.com/search.php?fontsize=1, rather than http://www.lfgss.com/search.php?searchid=12358533&fontsize=1

Mac OS 10.7.3, Chrome 17.0.963.46, fwiw (although it's prolly not a browser/os specific issue)

Yup, it's an edge case. Just hit New Posts again and it's fixed.