Forums

Unfortunately no one can be told what FluxBB is - you have to see it for yourself.

You are not logged in.

#26 2015-03-18 13:44:18

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,431
Website

Re: 2.0: Joining forces with Flarum

Flarum is FluxBB 2.0, that was my point. smile


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#27 2015-03-18 15:56:53

eric235u
Member
From: free software land
Registered: 2008-05-10
Posts: 132
Website

Re: 2.0: Joining forces with Flarum

I'm not able to receive the sign up or reset email from http://discuss.flarum.org/  Is he accepting new members?  Is his email broken?  Thanks for any tips.

Offline

#28 2015-03-18 20:09:20

muli
Member
Registered: 2015-03-11
Posts: 11

Re: 2.0: Joining forces with Flarum

My personal problem with all this JS-Stuff is, that it works as standalone whatever sometimes very well (but still slow most of the time). If you try to integrate it in your website or combine it with other "dynamic stuff", the problems starts, because modern sites, plugins,... also use tons of JS and then very often some stuff crashes (cause there is still other Ajax-Stuff, lightboxes, and so on and the code collides). Let's take a look at Google+ or also Facebook and similar. All working with "cool, dynamic, live stuff and content" and it reloads with some "magic"... but if you use them on slower computers, handhelds, smartphones or tablets, you'll feel that. If you load Google+ and Hangouts and maybe there are some Youtube-Videos inside the content... it feels buggy and slow.

The performance - a useful, simple cache-plugin (php) can solve a lot of things. Also Fluxbb is very "simple" - so you can modify it very easy (if you read a little bit or have low-level php-knowledge). Most users don't have a really idea of working with JS & Laravel Framework and will avoid that (in my opinion) to install it.

The reason why I (personal view) like Fluxbb and I say that AFTER using Mybb, Vanilla, PHPbb, vbulletin and so on - and the reason why it is "perfect", is: its very fast (click, click, click...zack, zack, zack, e.g. TextpatternForum or Archlinux-Forum with thousand entries), lightweight,  simple structure, don't need "exotic" stuff, you can also deal with it, when you have no idea of frameworks, ajax-stuff and so on... it's also very easy, to change things with little css and make it responsive and so on. Or to hide stuff with some css-tweaking and not to fiddling around somewhere with JS-Layers.

And also the "old" visual structure. Maybe that's not a very "modern" style, but if you reach 1000 entries, it's easy to get a overview, with categories and so on in the "table style". Vanilla, Facebook and so on, which are using this "new entries stream" are nice to stay up to date, but to scroll trough (old) content, it's sometimes difficult and the content get's (a kind of) "lost". Also the part by part loading of "more comments" - again loading circle, waiting, how to send somebody the solution somewhere in the discussion, where's the permanent-link? And if a company or agency block some parts of JS for security on the working stations, the site and their users have a problem. Archlinux, Textpattern and so on are good examples: fast, good overview, quick/fast to read, write, edit, scrolling.

I've also tested the flarum-demo with elinks and other textbrowsers - no sucess (but will follow maybe?) - which means users with readers (blind or disabled people) have a problem - Fluxxbb works very well here - you can read, log in, post, register, search also without GUI.

To be clear: I like Fluxxbb, because of the "minimalism". This doesn't mean, that Flarum is a bad decision, it can be cool, new and trendy and a lot of fun and useful. But it feels, that it is a complete "new/other thing", not a following project (also ok!) I understand the background, the excitement and curiosity - and have respect for your decision and also the fact, that you want to go to the "next step" - there is nothing wrong of it. So my textpart here doesn't mean: uh, new version and idea is bad. No, it isn't. It's just a personal feeling of "Mh, the next project, which follows FB-Google-Twitter-Vanilla-StackoverflowQuestions-Style". But also yes: there will also be users, who love this. smile And users like me, who love minimal, simple, stay out of my way-stuff. smile
*sorry, bad english*


*poor english, sorry for mistakes*

Offline

#29 2015-03-18 20:35:45

chris98
Member
From: England, United Kingdom
Registered: 2013-05-31
Posts: 1,276
Website

Re: 2.0: Joining forces with Flarum

Another thing I'd like to point out is that by adding loads and loads of JavaScript it, it gives much more room for error - and visitors shouldn't have to enable JavaScript to view a website anyway, it makes the standard user suspicious about what's going on, most of them probably don't even know what it is, and it's a pain to have to enable if not already (be honest - how many of you would know exactly what to do first time without having to check on Google first?).

Yes, Flarum may not require it, and shove popups in a user's face - but it will probably not work if it doesn't have javascript enabled. To me, it should be compatible with as many browsers (even old browsers like IE 7 & 8) as possible.

There is always someone who is clueless enough to not know how to upgrade or is experiencing such difficulties with it they can't be bothered to try and just stay with what they have.

The more JS stuff you add to a website (especially AJAX functions) the more room there is for JavaScript errors. I've even seen them on Google, Facebook and phpMyAdmin multiple times - sometimes you can stop it by doing the previous action again, sometimes you need to re-open the tab and others you need to completely re-open the browser after clearing cache.

IMO, JavaScript should be saved for basic form validation (as it is now) only.

Last edited by chris98 (2015-03-18 20:39:46)


Download Panther - The dawn of a new age in forum software.
Why should I use Panther? | Panther demo | Convert to Panther

Offline

#30 2015-03-18 20:47:05

eric235u
Member
From: free software land
Registered: 2008-05-10
Posts: 132
Website

Re: 2.0: Joining forces with Flarum

I really like not having to use javascript to view a site.  I use no-script by default on firefox.  Nevertheless js is the future.  Hell it's the present.  I hate the syntax, I don't trust it, etc.  I shall be happy and thankful to follow our devs lead.  I'll even learn more javascript.  If I'm going to be a web developer I need to know javascript.  Though I still want to be minimalist, and it appears so do our devs.  Maybe your use case is different.  My $0.02.

Offline

#31 2015-03-18 21:07:43

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,431
Website

Re: 2.0: Joining forces with Flarum

As far as I am concerned, progressive enhancement is the goal. I'm confident the forum will be accessible without JavaScript. So many worries... ;-)

That said, I'm glad for your input. It's good to remember what is important for you.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#32 2015-03-19 09:04:57

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 194

Re: 2.0: Joining forces with Flarum

@js
I tried to explain what I would like to see in a more current version of fluxbb 1.5: more convenience functions. Little helpers assisting the users. So eg. I described a function checking if there were new posts since you started writing your reply: this could be done with or without JS - either by a little ajax magic before submitting a form, or via an again displayed form if something was posted before submitting. Of course the "ajax" one is less intrusive as you just see a little tooltip mention that something has changed, please click submit button again to still send the post to the forum. The non-ajax-variant isn't the best for "used to use this board"-users as they might not wait for the resulting page to load (they submit, see that "redirecting page" or so and close the page).

But nonetheless it is possible to code this with and without jscript. This is even possible for approaches like "streams". The alternative to this is "pagination" which is something we _might_ know already (eg. if you are reading this thread now).

JS should only be used to pave another way to your functions, not the only way. Eg. Profiles could get loaded via an ajax call in a little box - or as a whole new view in another page. Same for "Searching", "BBCode help" etc.


But I am still not "happy" with Laravel and other frameworks ... of course it puts some of the workload to the framework devs ... but you get back "complexity" and "potential security holes" (the framework is used in many ways - so it will surely be more popular than the board software ... and therefor more often attacked/checked). You only save time when coding the whole thing with help of the framework. From then on ... you only get the drawbacks from frameworks (security, installation problems of new users, ...).
Do not forget: We talk about a board software, so nothing which needs to be versatile as hell (this could be reached in a more traditional manner). Of course this does not mean I am against a more "oop"-approach - because that makes extending - if needed - easier.

bye
Ron

Last edited by GWR (2015-03-19 09:08:47)

Offline

#33 2015-03-19 20:51:32

Gil
Member
From: France
Registered: 2008-05-10
Posts: 173
Website

Re: 2.0: Joining forces with Flarum

Again: do you think it is really difficult to have/build a flux with:

  • A (unique and strong) database structure

  • A (unique) backend (core & HMI design)

  • A common front-end core library

  • Two or several versions/offers of the front-end layer (for HMI design) above these common modules?

A forum that offers several different user experiences may be an attractive forum (real differentiator) and may expand the number of users.

On the contrary, I'm pretty sure that a unique javascript front-end will lose on the road a large part of the current fluxBB users.

Offline

#34 2015-03-21 09:03:09

tobscure
Member
From: Australia
Registered: 2015-03-16
Posts: 4

Re: 2.0: Joining forces with Flarum

Hi everyone,

Thanks for all of your feedback — keep it coming, we are listening!

The biggest concern that you’ve collectively voiced seems to be the fact that Flarum/FluxBB 2.0 is a JavaScript web app, so let me go into some more detail about the advantages and disadvantages of this approach and why we think it’s the right way forward smile

First, know that Flarum’s vision is a forward-looking one. Flarum is forum software for the future, a future where JavaScript web apps are the norm and Internet connections and mobile devices are fast enough to comfortably handle them. To paraphrase myself from my blog:

Forums are highly interactive applications — you’re constantly jumping between discussions and posting replies — all the while, new content is flowing in. So it makes absolute sense to use take advantage of JavaScript, giving the user instant responsiveness and creating a much more pleasant experience overall.

From a technical standpoint, the best way to build a JavaScript-heavy application is to use a JavaScript framework like Ember. This creates a nice separation of concerns (Ember is front-end, Laravel is back-end). The app can consume its own API, putting a mobile app or any third-party apps on the same tier as the official web app, and opening up a huge array of opportunities for extensibility.

Of course, this does pose some obstacles for accessibility. But rest assured that accessibility is still very important to us, and we’re not going to neglect it. In fact, after reading all of this feedback, we’ve been seriously considering whether the tradeoffs of using a JavaScript framework are actually worth it. Progressive enhancement is very difficult to get right, and there’s no one good solution (as I’ve gone into great detail about in the previous link). Here’s what we can guarantee at this stage:

- Flarum’s JavaScript assets, when minified and gzipped, will be hopefully no more than about 400 kB. On a modern Internet connection, that’s less than a second of download time; on all subsequent requests, the assets will be cached so the app will boot up immediately.
- Flarum will be fully SEO compatible: A static SEO-optimized HTML version of the page will be served up within <noscript> tags. Text/non-JS browsers will also be able to digest this content.
- Flarum will work absolutely fine with screen readers.
- Flarum shares FluxBB/esoTalk’s philosophy of minimalism and lightness, and we will do everything that we can to make sure that Flarum is as fast as possible. (The Ember.js devs are doing a lot of great work on performance too!)

I understand that this overall “futuristic” vision is not for everyone. Some people are quite happy with a simple, static HTML forum (like FluxBB 1.x or esoTalk) and that’s completely fine. I’m truly sorry we can’t please everyone, but I would encourage you to try to keep an open mind smile

To address some other specific concerns:

@muli @Franz Are you referring to having a list of recent discussions front and center? Not sure how or whether this will be baked in right away, but I'm sure there will be a simple way to start with categories like we always did with FluxBB.

The plan is to have Categories as an extension (installed by default) which will indeed add an option to start off on the categories page instead of “All Discussions”.

@muli Most users don't have a really idea of working with JS & Laravel Framework and will avoid that (in my opinion) to install it.

You won’t need to have any knowledge about these technologies to get Flarum up and running! The plan is to make an easy install script, which will be as simple as uploading a single .php file to your server and running it in your browser. The script will take care of the rest!

@muli Also the part by part loading of "more comments" - again loading circle, waiting, how to send somebody the solution somewhere in the discussion, where's the permanent-link?

You’ll notice on the Flarum demo that as you scroll through a discussion, the URL updates with your position! Refresh the page and you’re right back where you were. If you click on a post’s time, you can get a hard permalink ready to copy to your clipboard.

@eric253u I'm not able to receive the sign up or reset email from http://discuss.flarum.org/  Is he accepting new members?  Is his email broken?  Thanks for any tips.

Try again, and if you’re still not having any luck, let me know your username/email address and we’ll manually approve you smile

Toby (Flarum dev)

Offline

#35 2015-03-21 10:11:36

Moloch
Member
Registered: 2008-05-18
Posts: 12
Website

Re: 2.0: Joining forces with Flarum

Gil wrote:

I'm pretty sure that a unique javascript front-end will lose on the road a large part of the current fluxBB users.

I'd say from the postings here, and the other forum, these devs don't really care about the current user base. The condescending comments like "So many worries... ;-)" and "big scary Javascript app" are showing the true attitude toward the current user base; if we don't bend the knee to the new crown - off with our heads.

This is illustrated further with the comment "I'm glad for your input. It's good to remember what is important for you."

So is anyone working on a proper FluxBB 2.0?

All hate will be directed to /dev/null

Offline

#36 2015-03-21 12:51:54

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 194

Re: 2.0: Joining forces with Flarum

@400kb minified/gzipp'd

Do not forget that these are scripts - and 400kb (uncompressed maybe 700kb) will be a lot to manage for "low budget smartphones" (<= 1gb RAM). Glad "in the future" all of us will be wealthy and share the same super-duper-experience on the websites.

If you do not care for the lower percentage of your users, _I_ would say you are not a good person (socially and ethically wise). _I_ try to do my things in a way as much people as possible could benefit from it.
We are developers, so there is no need for us to take the easy way of doing things. Our (potential) users are what we want to entertain / allow to do things /... . I accept that obstacles in a developers route to satisfaction should be avoided, but you cannot just get rid of them. Sometimes we have  to jump/climb/... and maybe we learn things doing it (better climbing next time).


@seo friendlyness
What about static pages having "x posts per page" setups? store them too (possible as "storage space" costs up to nothing). Do not forget custom adjustments people use (personal "views").


@jscript - static pages - extensions
How to handle extensions then if everything is "pure js on top of seo friendly pages" ? People will need to write in both worlds: js to integrate data visually into the pure version of the page and the php-portion providing the data. Take this into consideration when planning the js-generation (hooking into the generation process joining the single js files + extension js-files).


To stop myself from writing something in the likes of "Moloch" I just sum up my current feeling: JS only is a 100% No-Go for me. As long as JS contains security flaws I will have Jscript disabled by default for all new websites I visit. Same for all personal computers in my household (so including the one of my wife). Same for computers I manage (grandparents, parents ... - they got their most visited websites whitelisted) and I am knowing others doing it nearly the same.
So all of us are the "lower bottom" of users you wont reach anymore. Why? To ease _your_ development path - which is (most of the time) not of interest for _your_ user base.

Main concern of a board software is: let people discuss things. It should _not_ matter if they are allowed (company rules) to use JS, or if they are capable of using JS (older devices -- maybe shared in the whole village).
It is up to the "owner" of the board to take the burden of increases server requirements.

That is why I said: JS is there to increase "convenience", not to replace things doable server-sided.


PS: I understand that there are "GUI/UX" done purely in JS ... for enterprise websites etc. - but there the company defines the "minimum requirements" and also is in the need to fullfill these. If _your_ software communicates with all people in the world, you cannot do this (exception here is "html + minimum css level", so even this has flaws...).

Similar to JS a board software should not rely on cookies, local storage, ... they should fallback to php-sessions to identify their users. But this is another story of broaden the potential user base.


@stateless html
This is not very useful for our board software (if it would be similar to the current board) as we do not do much "client side" stuff... where is not much dom-manipulation going on (creating gui widgets or so). So we still have the final first website render being kind of "first raw, then refined with css-styles" (depending on connection speed). Now the stateless-ajax-approach loads the desired subpage (after a click/touch) as a whole and cuts out what it needs _after_ transfering the data. The current board "approach" could benefit from only transfering the content-portion of the board (shaping off some kb for each request - important for "text only" boards for people having bad/limited connections).
Regarding saved requests (page request + cookie request [consisting of more than 1 call]): you will still have to validate yourself to the server via cookie or session-ID.
So like said: I do not see benefits using stateless html pages on the _user_side_ because it is up to the owner of the board to provide powerful servers for fast delivery, users should not care HOW things get created and delivered the fastest possible way.
But of course I understand that lowering the ressource hunger of your scripts is of interest for developers/hosts. As stated in the begin of my post the _user_ is the most important factor in "why I am hosting a board" - for me.

 

bye
Ron

Last edited by GWR (2015-03-21 13:00:46)

Offline

#37 2015-03-21 13:25:16

chris98
Member
From: England, United Kingdom
Registered: 2013-05-31
Posts: 1,276
Website

Re: 2.0: Joining forces with Flarum

tobscure wrote:

- Flarum’s JavaScript assets, when minified and gzipped, will be hopefully no more than about 400 kB.

Why should there be a need to minify? If you're needing to minify the output when sending to the browser in order to reduce the loading time, to me, that's a big indicator that the script is too bloated to start with.

Minifying scripts makes them much harder to read and debug - as well as alter future things to the script, I've learned from experience. It also adds more chance of corruption as you attempt to "un-minify" it.

tobscure wrote:

On a modern Internet connection, that’s less than a second of download time

While this may be "better" on a modern internet connection, a few of my members have shockingly bad internet, they even told me how bad it is. One of my moderators' internet speed takes about a minute for a page of FluxBB to load up as it is now.

tobscure wrote:

Flarum will be fully SEO compatible: A static SEO-optimized HTML version of the page will be served up within <noscript> tags. Text/non-JS browsers will also be able to digest this content.

I'm not sure which doctype declaration you're using, but this is probably another bad idea. For one, it's now deprecated in HTML 5, as well as a few other doctypes. The <noscript> tag should be avoided because it is handled differently by different browsers. Reasons to avoid noscript.

The noscript element should be deprecated, as it's better practice for
developers to design pages that work without JavaScript and progressively
enhance them using JavaScript, than assume JavaScript is supported
and then
provide some fall back content if it isn't.

http://www.w3.org/html/wg/tracker/issues/117?changelog

If you're going to be developing it with no JS and then optionally adding JavaScript in, that's even worse because it only adds more things to check, with nothing to gain, and bloats it up more.

GWR wrote:

That is why I said: JS is there to increase "convenience", not to replace things doable server-sided.

Completely agree with you there. It just bloats the script up and uses more space than necessary. Which is (part of) the reason IPB is so big (30.3 MB) compared to FluxBB (1.42 MB) - including some of my mods installed.

If I'm perfectly honest, I'd rather just stay with FluxBB 1.x - more care/attention seems to have gone into it to make sure it's very well optimised and doesn't seem bloated with useless features - for example, the Flarum "like" system built in.

Last edited by chris98 (2015-03-21 13:33:20)


Download Panther - The dawn of a new age in forum software.
Why should I use Panther? | Panther demo | Convert to Panther

Offline

#38 2015-03-21 14:17:59

Ledo
Member
Registered: 2008-05-10
Posts: 217

Re: 2.0: Joining forces with Flarum

Hi.

I remember when the future of FluxBB was disused and conclusion was it should be easier to do things like theming and writing extension. As i see it now it was probably too big burden/task to achieve this in reasonable amount of time. I am guessing that is why developers started thinking what should be the next step.

Joining forces with Flarum is i guess one option but it is probably something current user base didn't expect. Flarum looks like quite different project compared to FluxBB and i don't see much possibility FluxBB user base will jump over to Flarum any time soon (i could be wrong). I do see potential Flarum user base in the future if the project will deliver.

If (some) developers want to work on Flarum and start over good luck. About FluxBB i believe it should be clearly stated what the future will bring. Will anybody work on it or it will slowly fade out like PunBB.

I am guessing easier theming and writing extension for FluxBB like it was imagined for FluxBB 2.0 will not happen anytime soon. It was tried but it ended as too big obstacle to achieve for now.

I am guessing from FluxBB perspective if it will not fade out it makes sense to take FluxBB 1.5.8 and start over from this point. Probably it would make sense to focus directly on basics again (PHP/HTML/CSS and small amounts of JS) to see what can be done instead of using frameworks. If somebody is willing to do that lets see what will happen but if not FluxBB might fade out. Developers will work on something else and user base will search elsewhere.

Offline

#39 2015-03-21 14:39:57

Otomatic
FluxBB Donor
From: Paris - France
Registered: 2010-01-26
Posts: 539
Website

Re: 2.0: Joining forces with Flarum

Hi,

I will not go on a forum that uses such a big part of Javascript and quite frankly, I would stay with FluxBB 1.5.8 (+).
To develop and finalize the changes I need, it is completely out of the question to try to understand Javascript in addition to PHP. Especially for my needs, FluxBB as it is, with just my few modifications, is enough for me.
And, from what I can tell, Flarum's is all we want, but a forum.
For me, the ideal forums are the Usenet newsgroups (1). It's simple, easy, fast, without zigouigoui and it looks to substance over form.
(1) What I know and practice since 1986.


Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Ghandi
An error does not become truth by reason of multiplied propagation. Ghandi

Offline

#40 2015-03-21 15:09:01

Ledo
Member
Registered: 2008-05-10
Posts: 217

Re: 2.0: Joining forces with Flarum

I will cross my fingers and say i hope Flarum delivers.

Franz (FluxBB 2.0) and Toby (esoTalk) did work on the same goals in the past few years and basically used the same tools. Joining forces realistically should made Flarum progress faster. Flarum will probably become viable option if it delivers.

Question remains if there is still the need for forum software like FluxBB (1.5.8) and esoTalk. There probably still is demand for forum software like this and Flarum might not satisfy this demand.

Anyway good luck Franz working on Flarum and as for FluxBB i guess we will just have to wait and see how things will evolve over time.

Offline

#41 2015-03-21 15:43:33

GeekServe
Member
Registered: 2014-12-20
Posts: 5

Re: 2.0: Joining forces with Flarum

I have to say the news is rather disappointing, and leads me onto the search for another software that provides what FluxBB offers, and, what FluxBB2.0 was to offer.

My main concerns and reasoning behind the disappointment are down to the fact that both FluxBB and Flarum are quite evidently different in terms of their target... market? Flarum seems to be an attack on the social network-esque style of bulletin boards, think XenForo mixed with Twitter+Tumblr, whereas FluxBB is a super minimalist software with endless opportunity to grow.

I am not saying Flarum is bad, it is simply not what I am looking for, and clearly, neither is it what other (more prominent and well known) users of this community want. The current public demo of Flarum is to me, a mere headache to navigate, read, and understand what is going on.  But, I am sure that can be fixed up at some point in the future, whether it be by the developer, or by third-parties.

Flarum also sounds like it will also be a pain to seamlessly integrate into already-existing websites, which is something not too difficult with FluxBB.

To sum up, I simply don't feel the direction that FluxBB 2.0 was going in is the same as where Flarum is going, I can't see myself wanting to use Flarum for my already existing projects, I also don't think it is fair to tout Flarum as FluxBB 2.0, because it clearly is not.

Best of luck with it Franz, it's not for me.

Last edited by GeekServe (2015-03-21 15:54:33)

Offline

#42 2015-03-21 15:50:26

benjawi
Member
From: Plymouth, England
Registered: 2013-03-30
Posts: 81
Website

Re: 2.0: Joining forces with Flarum

400kb when minimised is huge. Fair enough for when using my PC, but not my phone. Quite a lot of mobile phone companies still don't offer unlimited 3g or 4g. Baring in mind as well that my phone (LG G2) doesn't have a mini SD slot so space on my phone is a premium - I've got it set to not cache anything as some apps and websites leave behind stupid amounts of information.

Biggest problem though is the doubling up on everything. One in Javascript and one for when Javascript isn't available. That's okay in small manageable amounts, but a whole website built with it? It's doubling the work and will likely double the code. That and the 400kb doesn't seem very lightweight and simple, which is what FluxBB is meant to be about.

Offline

#43 2015-03-21 16:02:34

eric235u
Member
From: free software land
Registered: 2008-05-10
Posts: 132
Website

Re: 2.0: Joining forces with Flarum

Moloch wrote:

So is anyone working on a proper FluxBB 2.0?

fluxbb/fluxbb2
https://github.com/fluxbb/fluxbb2/graphs/contributors

fluxbb/core
https://github.com/fluxbb/fluxbb/graphs/contributors

Last edited by eric235u (2015-03-22 17:07:43)

Offline

#44 2015-03-21 21:52:07

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,431
Website

Re: 2.0: Joining forces with Flarum

Moloch wrote:

I'd say from the postings here, and the other forum, these devs don't really care about the current user base. The condescending comments like "So many worries... ;-)" and "big scary Javascript app" are showing the true attitude toward the current user base; if we don't bend the knee to the new crown - off with our heads.

Wow. I don't think this is fair.

Moloch wrote:

This is illustrated further with the comment "I'm glad for your input. It's good to remember what is important for you."

What else should I say? I meant exactly what I said there. When I hear lots of FluxBB users being afraid that Flarum won't be good for them, that obviously worries me. When you voice your concerns, you can be sure I'm listening.

Flarum is not the end of FluxBB, it's not a completely new direction either. It's a new name for the next version, with more horsepower in the development team. FluxBB is not being abandoned, and not forked either.

The following seem to be some of the main concerns so far:
- Flarum is totally different than FluxBB. I'd simply say that's not true. As Toby mentioned above, having a category-style layout like FluxBB 1.x will totally be possible. The default style of an early alpha demo version is not the best indicator for the final design. If you want to help shape that, please join the development forum. smile
- Performance. I agree that 400kB would be a lot, we'll try to make it as small as possible. Performance is still a goal.

Thanks for the heads-ups in regards to <noscript> etc. It would be cool if you would open topics about these on the development forums, to be sure they're not forgotten.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#45 2015-03-21 22:14:39

wimc
Member
Registered: 2010-10-31
Posts: 109

Re: 2.0: Joining forces with Flarum

I'll wait and give my (positive/negative) feedback after FluxBB 2/Flarum are mature.

Also taking what Franz said, nothing is set in stone.

Offline

#46 2015-03-22 08:47:38

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 194

Re: 2.0: Joining forces with Flarum

- Performance. I agree that 400kB would be a lot, we'll try to make it as small as possible. Performance is still a goal.

This sounds as if you disregard the voices here (or did not clearly express yourself concerning JS usage): many/some/I of us are saying that "JS" should not be there to provide functionality the core does not provide (filesize, horsepower for displaying devices ...) . _I_ do not want JS to create anything "needed" to make the board work. If you only add convenience-functionality, you will be able to do everything in some KB. As it often is just ajax plus some fancy (flashing a div container, a small lightbox).


But... I do accept that the forum could benefit from having multple view-styles: threaded, flat, flat stream. All of them have things different to the other options. Threaded does not work well with the current "flat" approach. Newer boards have a "reply to X"-label on top of a post when displayed "flat" - maybe we could have something in the likes.


@categories
Instead of categories you could also call it "taxonomy" or "tags" as they are all doing the same: putting something in a list defined by something distinguishable.
With tags/taxonomy you would have of course to assign "parents" manually (for "subcategories") - or do it in a separate "taggroup"-table - which adds more sql-complexity.


@fluxbb usage
you also should think of what happens to bigger boards - some linux software uses fluxbb for their boards ... they are "some of your big customers", think about what _they_ would like to have.


bye
Ron

Last edited by GWR (2015-03-22 08:49:07)

Offline

#47 2015-03-22 10:39:17

seven
Member
From: Torino, Italy
Registered: 2010-08-19
Posts: 314
Website

Re: 2.0: Joining forces with Flarum

My humble thoughts:

1) the Air/Air2/Victory styles: their appearance is unmatched. Please do port them. Don't even bother with new styles, users looking at this board just notice that Air is how a forum should actually look. And Victory filled the responsive gap (with some minor edits).
2) a MVC framework is actually nice to have, even if that's some load thrown on the server. I don't know Laravel because I only used F3, but I guess I could learn it fast. Also, I don't really need a "mod load framework". An MVC application is definitely moddable by itself.
3) don't change the database! Ok, ACL for user permissions and salted passwords (phpass? please? please?) can be squeezed in, but the table layout - posts, topics, forums, categories, users - is simple, therefore perfect.
4) I'm not against JS, provided that it's indeed convenient to have it. I undestand the Flarum guy is doing the frontend, so it'd be stupid not to use his work. E.g., loading more posts while scrolling down the page is something Facebook does already and no one complains. Putting the reply right in the post is another thing JS can do when it's present. I agree 400K is biggish, maybe using a common framework available through CDNs would mitigate the issue.
5) Please keep the bells and whistles (social login, likes, karma...) as officially-supported mods. Or we'll come up with "de-mods", e.g. stripping them out tongue sorry, you already know the userbase here wants a barebones forum system.

Bigger boards will switch if the new software is not that different from now - same database, lookalike style. Same database means no need to port, lookalike style (HTML5, with added JS benefits, and responsive) would mean keeping their userbase.

Just my 0.002 € smile


gamezoo.org - serious gaming services for serious gamers.

Offline

#48 2015-03-24 13:45:15

XAOS-Eric
Member
Registered: 2013-10-16
Posts: 48

Re: 2.0: Joining forces with Flarum

A lot of you like FluxBB how it currently is without javascript, and that is the way FluxBB 2.0 needs to be. MyBB recently posted on their blog about their 2.0 you can see it at http://blog.mybb.com/2015/03/09/2-0-dev-post-1/. I for one believe that FluxBB 2.0 needs to be coded with php and minimal javascript, and I will fight to keep our version of 2.0 alive.

If Franz wants to work on Flarum that is fine, but let someone that has time to work on FluxBB 2.0 the way it was meant to be take over development of FluxBB so we can keep this community alive. It would be a shame to see FluxBB die because one person doesn't want to hand over the reigns if they want to work on a different forum software.

The FluxBB community is speaking out against merging the project with Flarum, and it is time for Franz to rethink it and allow the communities to split, FluxBB is a community project, one person alone should not be able to make the decision to end development of FluxBB, there will be forks, and one way or another development of what we have so far of FluxBB 2.0 will continue.

Last edited by XAOS-Eric (2015-03-24 13:46:27)

Offline

#49 2015-03-24 13:54:08

Visman
Member
From: Siberia
Registered: 2010-07-10
Posts: 1,103

Re: 2.0: Joining forces with Flarum

All of these ideas with the transition forum to framework erroneous wink


My modification of FluxBB 1.5.10 - rev.76 * Parserus - BBCode parser
I speak only Russian  tongue

Offline

#50 2015-03-24 14:33:10

chris98
Member
From: England, United Kingdom
Registered: 2013-05-31
Posts: 1,276
Website

Re: 2.0: Joining forces with Flarum

The FluxBB community is speaking out against merging the project with Flarum, and it is time for Franz to rethink it and allow the communities to split, FluxBB is a community project, one person alone should not be able to make the decision to end development of FluxBB

If Franz wants to work on Flarum that is fine, but let someone that has time to work on FluxBB 2.0 the way it was meant to be take over development of FluxBB so we can keep this community alive.

Yeah - I agree with you XAOS-Eric, I think if Franz would rather merge with Flarum he should let someone else take over the reigns here, it would be better to have two different softwares, they are not alike, and are never going to be. If anything, Flarum should be the software merging with FluxBB over here, for one FluxBB is older and there are more people on the development team. With Flarum, it's only Toby developing, and now Franz - not that I have a problem with that for Flarum, but Flarum is always going to be smaller than FluxBB and FluxBB will always be more popular/well known.


Download Panther - The dawn of a new age in forum software.
Why should I use Panther? | Panther demo | Convert to Panther

Offline

Board footer

Powered by FluxBB