Wedge

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

Why did you come back from xenForo? I thought everyone loved it... (Except for me, but I haven't actually played with it much. Never bought it, never registered to a xf forum, etc.)Bloat = a load of extra features that are presented to you and you don't really need, and bother you more than anything.
How to avoid bloat? With one or several of these solutions:
1- Make sure the extra features don't make the software slower. If it's not possible, make sure they can be disabled, and that they don't slow it down if disabled.
2- Finetune the front-end and back-end interfaces to make sure they don't jump at the user or the admin. They should be there, but discrete. If someone doesn't want to use the feature, you shouldn't remind them that they are to use it.
3- Generally, make sure the feature is actually useful to at least a good portion of the community...!It's not going to happen that way. Although it's likely (because SMF repeatedly said "we're just a forum", and we're saying the opposite), the SMF team and us aren't in touch, and we're not developing two opposing branches of the same software -- we're just developing them as we would LIKE it to be, while they're developing it as they THINK people would like it to be. That's a major difference. In our case, we may fail to attract a large user base, but we will definitely appeal to like-minded (perhaps more tech-savvy) people.We've already gotten rid of the majority of what we thought was unneeded. Pete had a lot of fun removing huge portions of SMF like support for PGSQL and SQLite, or PHP4, things like that. What was valid for SMF2 when it was built, isn't always valid 5 years later. Well, PGSQL and SQLite may be very well alive, but it's quite obvious at this point that people who use it, ALSO have a MySQL server installed somewhere, making it pointless to use PG or SQLite. Ultimately, that was a load of bloat. (The best example being the extra empty parameter at the beginning of each query... There's no logic in using global $smcFunc; $smcFunc['db_query']('', 'SELECT * FROM {db_prefix}table'); when you can achieve the same in Wedge using wesql::db_query('SELECT * FROM {db_prefix}');....)We haven't started work yet on extended profiles. Blogs are underway, gallery is being developed in parallel and hopefully I'll start integrating it into Wedge soon. (I still have a few minor changes I need to do before I, ahem, break Aeva Media and Wedge altogether for the time it takes to make them behave.)Generally, just have a look at noisen.com and consider that all of its features will end up in Wedge one day or another --- because my goal is to switch Noisen to use Wedge, obviously. I have no commitments other than that. And it's already a lot -- took me a couple of years to refine Noisen to what it is, and it doesn't even need to be open to more server types... While Wedge needs to take all kinds of server setups into account.Well that's already in AeMe2...There's a difference between a perceived performance hit, and an actual performance hit.
Just like jQuery: if you include it at the start of your source code, it will slow down your first page load. If you put it at the end, it won't slow down anything, even though it's the same code. jQuery is slower than native JS, but if you handle it correctly, it's fast enough. (e.g. if you're using jQuery discovery functions inside a large loop, you may wanna look into using native JS instead.)Yeah, never wrote that, never looked into it, but it's in my future plans. Far future though... Importing external data into a board (i.e. new topics each time) isn't my thing, though. If it were to be done, I'd give the ability to import into new posts inside a specific topic, things like that. Also -- importing and exporting in/from thoughts. (Kinda like my own tweeter/FB wall on noisen.com...)Karma was removed long ago from Wedge. The Like system isn't implemented yet because we're unsure how BEST to implement it -- i.e. it should be extremely flexible and would be handled as part of our floating topic system (more on that later... Well, if we end up discussing it publicly at least.)Well, if you look closely, you'll see that Wedge.org has got over 10k posts since its inception... Meaning we definitely talk a lot ;) Only, in private. Many of the things you mentioned were discussed over at the private area, really.Not by me, I'm not a big fan of portals (having never used one more than 10 minutes.)
However, I made it extremely easy to add code to the sidebar (Wedge has a 'mandatory' non-intrusive sidebar.)
It's just a matter of sending a call to showSubTemplate('my_function', 'sidebar'). Really, piece of cake.

(BTW, note to Pete: the function that shows the sub-template is loadSubTemplate while the function that just loads it for later use is showSubTemplate... Although it does make sense when reading the source code especially next to loadTemplate calls, it's kinda awkward when you come to think of it :lol: Maybe I should do an automatic search & replace to swap the names...?)

Re: RSS feed and extended profiles... Just a quick Google search on your made me understand :angel:

That's the other way around actually.
And you are.........?
Where did you find this website?

rev 670
(5 files +1, 20kb)

+ Added support for version number of main browsers (IE, Opera, Firefox, Chrome, Safari), via a floating point number. (Load.php, Class-CSS.php)
- Removing a work in progress that I committed by mistake in the wedge.org renaming batch: alternative quote handling in Post.php. Moved it to the wip folder instead. (Post.php, other/wip/Post-alt-quotes.php)
@ Also committed another WIP by mistake, in Load.php this time, but it's working, so I'm leaving it in, hopefully we'll end up using it: on_date() function in Subs.php, which does all the work on 'on January 1st / today' formatting. It's just a single line though... (Subs.php)
! Board status icons were broken in IE6. (ie6.css)
- Removed useless img styling. (Pastel/index.css)

rev 669
(5 files, 7kb)

! Fixed wrong alignment for category headers in IE6. (BoardIndex.template.php)
! Fixed header styling in browsers that don't support the header tag. Uh. (index.css)
! Fixed more IE6 issues: menu toggler arrow in IE6, and various minor details. (GenericMenu.template.php, ie6.css, index.css, rtl.css)

rev 667
(5 files, 10kb)

* Changed headers to actually use the header tag now... Might as well start using HTML5 tags now! (*/settings.xml)
! Oops, forgot to actually commit Class-CSS in the previous rev... (Class-CSS.php)
* Turned gradient_background and rgba2rgb into static methods, and fixed rgba2rgb to actually stop using class variables. (Class-CSS.php)
! Forgot to add a PNG workaround for IE6 in Wine's footer logo. (Wine/settings.xml)

rev 666
(14 files, 21kb)

! A selector followed with "extends something" needed to have at least one child property (the alternative being to use "base: something" as a property) -- this is no longer the case, indentation is enough to point out that the selector is just supposed to inherit something else. (Class-CSS.php)
! Some fixes to the object logic (visibility and instances). I'm starting to grasp how it works. Yay. (Class-String.php)
! Re-split top page IDs into three single anchors as they used to be. This is because the page won't validate otherwise. Uhhhhh. (Display.template.php)
- Don't show the window resize script in IE6 and IE7, as the current table-based solution isn't out-of-the-box compatible with the display:table one. Also made the related function a bit shorter. (index.template.php)
* we:title2 should only be used when within a hierarchy below we:title... Also, RSS header text was missing some white space. (index.template.php)
- Removed 'p' tags inside prev/next links. They were a leftover from a previous hack... (Display.php)
- $substr wasn't used in westr::cut. (Class-String.php)
* More stuff needing white space. (Stats.template.php)
* Indenazi. (index.template.php, Memberlist.template.php)
* Some 'Allons-y, Alonso!' tweaks to the language files. (index.*.php)
* Tidbits. Dozens of minor changes that aren't worthy of a changelog line, but are still there. Mostly, remnants of my epic but failed attempt at introducing a general vertical alignment process. (Post.template.php, ie6.css, ie7.css, index.css, sections.css)

Note: I forgot to add the Class-CSS.php file to the commit list. Will be in #667, as soon as I find a sec' to look into the instance crap.