XenForo 2.0 Discussion

Status
Not open for further replies.
At some point won't there be a need to find an alternative to JavaScript? Excessive JavaScript commands can greatly impact pageload times for a sites. Ergo it impact the number of add-on's you can install.
The word in bold is what matters.

As computers get faster and JavaScript specifications (along with best practices) improve, there is little need to specifically cut some features in order to make up for page load times. Instead, you should be looking into the quality of the addons you install, not the quantity.

(Plus, there are no alternatives to JavaScript, at least in the foreseeable future.)
 
My main suggestion is to rigorously rethink and rework the language packs approach and the current phrase system, because its hurting international and non-English communities the way it is now.

I'll explain why I suggest such a radical thing:
  1. It can take an addon developer a lot of time to simply search and replace each instance of the same word throughout the phrases system. Simple tasks are complex and time consuming here. The interface could be improved a lot to cater to developers.
  2. After 5 years of xenforo there are quite a few languages for which there barely are any good language packs around. Not many people want to translate a whole pack with thousands of phrases. It's a monks task, so we should be happy to have any language pack.
  3. Translations should not rely on webmasters. End users should do it. That would be a game changer.
  4. Please consider translations of user generated content. Not just interface phrases. Its not possible to offer a translation of a resource or a page. This same problem extrapolates to addons.
  5. It should not be the case that only parts of XF can be translated.
  6. Google will index all forums as the same language and therefore multilingual forums hardly gain any traction.
  7. Users will always see all forums, even if the forums are in a language they can't read.
  8. Users should be able to search in their language.
  9. XF should consider the language that a browser defines.
Translations does not equal localization. The latter is what international communities need. XF offers only partial translations not comprehensive localization.

Phenomenon like Reddit, Facebook, Wikipedia, etc are successful at the expense of our communities, in part because they offer an experience tailored to users in all countries and languages. We have the handicap that we cannot offer this.

I also think the language system could be improved.
What I'm missing.

- Translation of nodes
- Translation of pages
- Translation of user content
- hreflang tags (so search engines understand which langue you are using)
 
The word in bold is what matters.

As computers get faster and JavaScript specifications (along with best practices) improve, there is little need to specifically cut some features in order to make up for page load times. Instead, you should be looking into the quality of the addons you install, not the quantity.

(Plus, there are no alternatives to JavaScript, at least in the foreseeable future.)

The computers, mobile devices and servers we use today are plenty fast. Greedy ISP's overcharging for bandwidth and limits on mobile devices are causing a lot of the issues we have with pageload times today.
 
The computers, mobile devices and servers we use today are plenty fast. Greedy ISP's overcharging for bandwidth and limits on mobile devices are causing a lot of the issues we have with pageload times today.
HTTP2, request compression, CDNs and general JavaScript minification (already in use with XenForo) will all help with that, but even then a typical XenForo page is only about 200KB (excluding images, and depending on how much text you have), with subsequent page loads being at most 25KB because of the cached JS/CSS. Even if they use state-of-the-art libraries such as Ember or Angular, both of which are known to have a very large filesize because of how powerful it is, it should not go beyond 500KB, and the ISPs I have come across that implement data caps count by MBs.

Rather than worrying about saving a few KBs to cater for greedy ISPs, XF should first focus on building the forum experience they want to deliver; any optimisations in file sizes can come later.
 
The computers, mobile devices and servers we use today are plenty fast. Greedy ISP's overcharging for bandwidth and limits on mobile devices are causing a lot of the issues we have with pageload times today.
My ISP caps my 100mbit connection at 150gb per month, I fail to see how that affects anything really, if you get slowed after a certain limit that's your data management problem. if you have a 5MB cap on adsl get a new ISP.
 
My ISP caps my 100mbit connection at 150gb per month, I fail to see how that affects anything really, if you get slowed after a certain limit that's your data management problem. if you have a 5MB cap on adsl get a new ISP.

Well not everyone has that option. Some of us live in the sticks with only one option for home internet. So to say if you have this on this then find a new ISP. If it were that easy then no one would be having issues with speed and needing things to load faster on slower connections.
 
Well not everyone has that option. Some of us live in the sticks with only one option for home internet. So to say if you have this on this then find a new ISP. If it were that easy then no one would be having issues with speed and needing things to load faster on slower connections.
Or if your audience is people in less-developed countries.
 
I'm ireland for 3g4g "Unlimited" is a cap of usually 5GB, and yes they sell it as going on a bing watch of video when the rest of us know 5GB of bandwidth is nothing. Thankfully wired connections are not so bad .

You have to consider device power, not everybody has an iPhone or flagship android in their pocket.
 
Is it really THAT BIG rewrite?
Well, let's see
  • Significant changes to code organization to improve code reuse (or reusability) and to help add-on developers apply additional changes to existing code more easily
  • Most likely a navigation menu manager (which would most likely break many current styles & add-ons)
  • fundamental changes to some of the lowest level code in XenForo, notably models and data writers
  • LESS is now the primary language for styling
  • template syntax has changed to some degree to provide more flexibility
  • a generic payment framework
  • organizing code into services with minimal external dependencies
Those are just a few things that have been indicated... so yes, I'd say it's a pretty big re-write. Probably along the lines of the IPB 3.x -> IPS 4.x line.
 
Is it really THAT BIG rewrite?
My comment from Feb 6, 2015;
Otherwise, XF 2 isn't going to be released for years and years. I would be surprised if a usable product came out inside 2-3 years if XF was being fully rewritten.
And from March 21, 2016:
Given the scope of the changes, there is probably another 6 months to 1.5 years of development time before they have a releasable alpha/beta.

Remember; they need to update every official add-on too.

This thread was started in Jul 30, 2014, we are coming up to 2 years from the initial announcement.

Late 2016, or early 2017 for a semi-stable alpha/beta may be possible. But without more information, I'll just keep incrementing my "expect XF2 in yyyy year" counter.
 
Status
Not open for further replies.
Top Bottom