[FAQ] Minimum requirements
[FAQ] What is Wedge? »

Nao

  • Dadman with a boy
  • Posts: 15,932
[FAQ] Minimum requirements
« on October 1st, 2010, 06:32 PM »Last edited on January 20th, 2014, 10:37 AM
Minimum requirements

Client side:

Opera 9 or higher, 12 or higher recommended.
Microsoft Internet Explorer 6 or higher, 10 or higher recommended.
Mozilla Firefox 2 or higher, 17 or higher recommended.
Apple Safari 3 or higher, 6 or higher recommended.
Google Chrome (any version), 27 or higher recommended.

JavaScript is strongly recommended
Cookies are strongly recommended
Flash is recommended for media embedding

Server side:

PHP 5.3 or higher
MySQL 5.0.3 or higher
GD2 graphic library for PHP


[FAQ] Re: Minimum requirements
« Reply #2, on March 28th, 2011, 08:23 AM »
Not very extensive, yes, yes, and jQuery.

[FAQ] Re: Minimum requirements
« Reply #3, on March 28th, 2011, 09:43 AM »Last edited on March 28th, 2011, 07:07 PM by Nao/Gilles
Quote from Xarcell on March 28th, 2011, 02:44 AM
I noticed that IE 6 is a minimum requirement, but how extensive will the support for it be?
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%)
Quote
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.
Quote
Is jQuery going to be used, or are you guys writing mostly your own?
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.

[FAQ] Re: Minimum requirements
« Reply #4, on March 28th, 2011, 07:02 PM »
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.

[FAQ] Re: Minimum requirements
« Reply #5, on March 28th, 2011, 07:17 PM »
Quote from Xarcell on March 28th, 2011, 07:02 PM
Wow, you really know your shit.(that's not sarcasm).
Well, I'm a good learner.
Quote
I hate seeing js file sizes over 25k, but that's just me.
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 :))
Quote
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...
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.
Quote
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.
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...)
Posted: March 28th, 2011, 07:15 PM

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.)

[FAQ] Re: Minimum requirements
« Reply #6, on June 19th, 2011, 11:04 AM »
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?
Quote from Nao/Gilles on March 28th, 2011, 09:43 AM
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.)
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.)
Quote from Nao/Gilles on March 28th, 2011, 09:43 AM
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.
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.)
Quote from Nao/Gilles on March 28th, 2011, 07:17 PM
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.)
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]

[FAQ] Re: Minimum requirements
« Reply #7, on June 19th, 2011, 06:43 PM »
Quote
Why might Flash be required?
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.

[FAQ] Re: Minimum requirements
« Reply #8, on June 19th, 2011, 07:05 PM »
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.

[FAQ] Re: Minimum requirements
« Reply #9, on June 19th, 2011, 07:07 PM »
That is only for mass upload, and that can be replaced with the newer JavaScript File API since it supports upload progress.


[FAQ] Re: Minimum requirements
« Reply #11, on June 19th, 2011, 08:33 PM »
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]

[FAQ] Re: Minimum requirements
« Reply #12, on June 19th, 2011, 08:51 PM »
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.

[FAQ] Re: Minimum requirements
« Reply #13, on June 19th, 2011, 09:15 PM »
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?

[FAQ] Re: Minimum requirements
« Reply #14, on June 19th, 2011, 09:16 PM »
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*.

[FAQ] Re: Minimum requirements
« Reply #15, on June 19th, 2011, 09:35 PM »
And the OP does say recommended, not required ;)

[FAQ] What is Wedge? »