Wedge

I noticed that IE 6 is a minimum requirement, but how extensive will the support for it be?

Have you guys looked at CCS3pie for IE and jQuery png transparency fix for IEIs jQuery going to be used, or are you guys writing mostly your own?

Not very extensive, yes, yes, and jQuery.

It won't explode, and it's already a lot.
Outside China, the IE6 market share is now <5%, so it's no big loss if it doesn't look good on these. It has, however, to work, since Opera's market share is not much different and I'm using it as my primary development platform. (A matter of logic, I'd say.) I'm not testing support for Firefox 1.x and 2.x though, ah ah. (<0.3%)You don't need jQuery to fix IE crap... You don't need CSS3Pie either, anyway. If you look closely into the css3pie boards, I posted over there back in September to report bugs and post their fixes. I then wrote and recompiled my own version with only support for rounded corners (much smaller file). Then I recently dropped it because IE6, with its slow JS engine, is "watchable" but not "usable" in a 'hack' environment. I decided that IE6 users don't deserve any hacks anyway. If they're going to use a shitty browser, they'll get shitty graphics. The only thing I'm making sure is IE6-compatible, is the JavaScript stuff. I don't like error popups.
Anyway, once we start releasing our files, I'll probably stop testing for IE6 myself. People will be able to report bugs and stuff that were introduced in new builds, but I won't change Wedge to make it behave perfectly in IE6.
Yes, SMF does it, but remember that SMF2 was started back in 2005, when IE6 still had a 90% market share. We're six years later and they're still treating IE6 support as sacred or something.We included jQuery but mainly for user interest. i.e. we don't actually need it ourselves, but we figured that since it's the de-facto library for developers, many would be happy to see it included by default, avoiding the need to include the library separately (potentially breaking other mods using it in the first place.) Everything is taken care of for them. However, early versions of $ had a reasonable filesize. Now, v1.4.4 is about 24kb after gzipping, which is scandalously big. It pretty much makes it hard for 56k modem users to run a site that uses jQuery. And the newest 1.5.x branch is even worse (I suspect v1.5.3 will finally reach the 30kb limit.)
We're currently using 1.4.4 because we don't need more, but support for the latest versions seems pretty much mandatory to me. Admins have the ability to choose whether to load jQuery locally or from a CDN (I would recommend the CDN, if only because you get the benefit of cross-domain caching.)
I don't really know what to do about the filesize all in all, but I know that I spent a LOT of time optimizing the source code and templates to actually make it faster to load Wedge than SMF. (Even with aforementioned 56k modem.)

I guess I still haven't found my peace with jQuery. It has some nice features, but nothing that we couldn't implement ourselves. Hopefully, v2.0 will be modular... But I suspect that even if they added some kind of modularity to it, it would still be bigger than the entirety of 1.4.x.

Wow, you really know your shit.(that's not sarcasm).

I hate seeing js file sizes over 25k, but that's just me. If your capable of writing your own, that will work best, it's just more time and bug tracking involved. User's can still add jQuery manually, that's the route I would take. I see no point than have both. But I am a fan of jQuery, and can't stand Mootools...

As far as IE6 goes, it's good to hear it won't be babied like SMF does. People need to upgrade. Most of the current IE6 users are from businesses anyway.

Well, I'm a good learner.Me too... But that depends it it's gzipped or not.
Wedge automatically caches and gzips all CSS and JS files. It's a feature I spent a lot of time working on, it's working perfectly in all browsers and it really saves a lot of bandwidth if your server doesn't let you enable gzipping automatically on files. (Plus, you save the processing time for gzipping files in the first place, as they're only gzipped once and then cached, as opposed to gzipped on the fly each time the file is requested in SMF for instance.)
Anyway--
The main script file (script.js+theme.js) is 28kb in Wedge (compared to 50kb in SMF for the same data), and gzipped to 10kb, meaning script.js+theme.js+jQuery = 37kb in Wedge, compared to the original 50kb (uncompressed) in SMF. All in all, if your server doesn't support automatic gzipping, then you actually save 13kb of bandwidth per user per session, *and* they get jQuery in the process. (Plus, since you can load jQ externally, you really save a whopping 40kb and an unneeded extra hit :))I'm not fond of Mootools either. Or Yahoo's solution, for that matter. jQuery is best, but it still has the problem of bloat over time. Sometimes, smaller is better, really. Even switching to Google Closure then to UglifyJS didn't save the library from getting bigger.Yeah... Mainly because many businesses are still running Win2k, where IE6 is the last available version. (Of course, they could use modern browsers that work even on Windows 98, but...)

Re: filesize, it's also less of an issue when files are loaded at the end. That's where perceived loading times come into play. The only thing that's slower in that situation is the execution of JS functions. But that only means your code should behave as if the browser doesn't support JavaScript for a couple of seconds, and then JS takes over. It's as easy as that. (Of course it's not really exciting to write fallbacks for non-JS but you can always simply skip that and just expect people NOT to click everywhere in the first two seconds of loading your website for the first time... Which is, let's just say it, totally unrealistic. The act of clicking so quickly, I mean.)

I wouldn't waste my time with the Chrome 1 requirement.  You would be surprised at how hard it is to lock Chrome to a single version.  I don't think it's worth worrying about older than 6 or 8 or something at this point, and even probably not that far back.

Why might Flash be required?I am constantly astounded by how many nifty features (like deferred) I never have any use for, and how many much simpler core things that I've used in my own js libraries it completely misses (like currying.)Ha.  Well, at least they definitely know what they're doing.  It's becoming a standard though, such that I wouldn't be surprised if it goes the way C did: Intel optimizes CPUs for C, so if you don't use C, your code is slower.  This is why all languages are based on C's rules nowadays.  I expect Jaeger and V8 and etc. to get optimized for jQuery, so it's probably going to become a standard.  If it keeps getting more popular, I suspect it'll be bundled and detected at some point by browsers for further perf wins (since we're currently in a perf war.)You can get some good wins out of deferring some of the js.  I'm going more the js app route myself, so a mere 20K doesn't sound like a lot (although it all adds up.)  I'm currently more in the realm of 270KB (before deflate or minification, about 41KB after) but I late-load about half that.  This is for a relatively complicated piece of internal software, though.

-[Unknown]

Because we've been bold. Nao and Dragooon between them created SMF Media Gallery, later Aeva Media, which got in-built into the core. Maybe that's controversial but from where I'm standing it's a good idea. We're not aiming for the hard-core "I'm a forum through and through" demographic, never were.

So, there's a full blown media manager/gallery in the core now, and it's going to be tied in deeper. If you have a media management system, it's not illogical to replace conventional attachments with it too, and since media items can be embedded with bbcode, you get the ability to place 'attachments' wherever in the post you want them - great for blog entries, for example.

But since it is a media manager with video handling, it does often have to handle things that HTML5 can't, plus the player currently in use for uploaded MP3 files provides a nice graphic equalizer, which is all Flash implemented.

Correct me if I'm wrong, but I believe Flash is being used to assist the media uploading process as well, i.e. to show progress bars.

That is only for mass upload, and that can be replaced with the newer JavaScript File API since it supports upload progress.

DIE FLASH!

Would that still make it a requirement?  If an optional feature doesn't work, it seems like a recommended thing not a minimum requirement.

When I buy a game and don't see fancy shadows, it's not because my video card doesn't meet the minimum requirements... it's because it doesn't meet the recommended ones.

-[Unknown]

Mhmm....game...fancy shadows.......Crysis!

Although I agree, Flash being a requirement is ridiculous even when the general shift is against it. It being recommended is totally reasonable though.

I'm fu**ed with flash anyway.

Every time I want to see something made with flash I need to open Windows 7

It is OK in Linux 32b but my main computer uses Linux 64b and flash doesn't works well there. Every now and then it works for a while, but as soon as Adobe make an update that's it. Gone again.

What's the point on having computers with so many Gb of RAM if they don't care about 64b systems?

True, I guess.

Though if you're using the video embed option (a la embedding YouTube from a link) it will also use the Flash version IIRC. It's not *required* but it's a bit past *strongly recommended*.

And the OP does say recommended, not required ;)