Forums

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

You are not logged in.

#51 2015-03-24 14:37:07

Meow
Member
From: Taipei, Taiwan
Registered: 2008-05-10
Posts: 677
Website

Re: 2.0: Joining forces with Flarum

People here worry about Flarum too much. Having known both of FluxBB and esoTalk for long time, I could say that Toby is a perfectionist.


Enjoy the chosen furry artworks on Chita every day.

Offline

#52 2015-03-24 14:44:10

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

Re: 2.0: Joining forces with Flarum

Sorry, but from what I've seen I can see that Flarum is anything but perfect. I imagine other the other members also feel the same way.


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

Offline

#53 2015-03-24 15:25:16

Askelon
Developer
From: Bretagne − France
Registered: 2010-06-09
Posts: 202
Website

Re: 2.0: Joining forces with Flarum

Well, I think I won't be using Flarum, even though I understand the underlying choices and I do support the joining with Flarum.

However, I have to say I'm very disappointed by the reactions to the announcement more than the announcement itself. Some took no soft ways so I won't either: if Franz feels like this is the way FluxBB should take, so be it. FluxBB is free, anyone not happy with that decision can start their own forks. I'll probably be doing that too. There are already a few out there that look promising enough, ModernBB/Luna being the first to come to mind.

Flarum may not be what you're looking for, but from what I saw it looks like it could bring some very interesting features for users. I get it that some people don't like JS but, please. 2015, guys. Even in my professional contacts I can't even think of more than 2 people not using JavaScript. Unless you're running a forum for a couple of geeks using lynx, JS will be enabled. And it will provide very useful features. For what it's worth, I think that's the point: offering features to users. Not accommodating grumpy developers.

Offline

#54 2015-03-24 16:12:56

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

Re: 2.0: Joining forces with Flarum

tobscure wrote:

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:

Firstly, your your joking right? JavaScript web apps will never be the norm as long as there are people that don't have good bandwidth. If you wanted a javascript based front end that is what NodeBB is for, no need to reinvent that wheel, even the backend of NodeBB is coded in JavaScript and look how much of a user base there is for that.

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.

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?

This is the reason I am fighting tooth and nail to keep our vision of FluxBB 2.0 alive. There is enough community support behind FluxBB to keep 2.0 alive. What makes FluxBB unique? We are a community, and we shouldn't let FluxBB or our version of FluxBB 2.0 die just because one person decides they don't have time to properly code it. The old lead developer of MyBB stepped down and handed on the reigns when he didn't have enough.

We as a community are speaking up and calling for @Franz to not force Flarum's version of FluxBB 2.0 among us and allow our version of 2.0 to continue to be developed, and if Franz can't allow that, then it is time for someone new to take over development of FluxBB.

Offline

#55 2015-03-24 16:19:32

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

Re: 2.0: Joining forces with Flarum

Askelon wrote:

However, I have to say I'm very disappointed by the reactions to the announcement more than the announcement itself. Some took no soft ways so I won't either: if Franz feels like this is the way FluxBB should take, so be it. FluxBB is free, anyone not happy with that decision can start their own forks. I'll probably be doing that too. There are already a few out there that look promising enough, ModernBB/Luna being the first to come to mind.

If we as a community speak out loud enough to be heard, FluxBB and our version of a php based 2.0 without the JavaScript web app part doesn't have to die. We just need to stick together in this time of shocking news, and hope that Franz will either see the light and go back on the decision to merge with Flarum, or allow someone else to take over development of FluxBB that will allow the community as a whole to go down the path we want to go down for FluxBB 2.0.

Offline

#56 2015-03-24 22:46:58

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

Re: 2.0: Joining forces with Flarum

Askelon wrote:

However, I have to say I'm very disappointed by the reactions to the announcement more than the announcement itself. Some took no soft ways so I won't either: if Franz feels like this is the way FluxBB should take, so be it. FluxBB is free, anyone not happy with that decision can start their own forks. I'll probably be doing that too. There are already a few out there that look promising enough, ModernBB/Luna being the first to come to mind.

You're right. Franz (who already was highly active in the 1.5 the branch; For that, I thank him) is almost the only active developer of flux 2.0 and as such, it is clear for me that he is free to decide another new turn for fluxBB; But you forgot the last sentence of his post; Franz also asks us:

Franz wrote:

Please let us know any feedback you have - we want to hear your comments, questions and concerns.

It's not our fault if there are more bad/suspicious reactions/feeling that good ones!

Askelon wrote:

Flarum may not be what you're looking for, but from what I saw it looks like it could bring some very interesting features for users.

For sure; I don't think that anybody can say otherwise. It could.

Askelon wrote:

And it will provide very useful features. For what it's worth, I think that's the point: offering features to users. Not accommodating grumpy developers.

I disagree. Or rather it depend's: is integration capacity not a good feature to offer?

Laravel was a first very important turn in the life of the future FluxBB. I'm sure that some people did not want to follow this new way, but it should also have been an opportunity, especially for website integration (design of course, but not only design). Here is another very important turn, before a first beta Laravel version. I don't say that the future flarum will be a bad product, of course not, just that my opinion is that this second major turn is not a good idea nor a good news for the fluxBB community.

Offline

#57 2015-03-24 23:11:13

Askelon
Developer
From: Bretagne − France
Registered: 2010-06-09
Posts: 202
Website

Re: 2.0: Joining forces with Flarum

@Eric: I don't know where comes that idea that Franz -- or anyone working on any project, for that matter -- would owe anything to a community in terms of decision making. That's not a hard concept to grasp: there's a project, and leaders behind that project. Leaders can, and should, listen to the opinion of the community; but there's nothing binding them to simply back down and do whatever the community demand everytime they feel otherwise. In the end it all comes back to the people building a project, not those using it. They get the final decision. The counterpart is that users are freemto go out and use simething else whenever they want. Put it simple: opinions, not commands. That's exactly why forks exist: to change direction when you think the project is not going the way you want it to go. Go and fork! What do you care if FluxBB doesn't meet your needs anymore? If your fork is good enough, people will use it, including me. Plain and simple.

You said it: it's about your vision vision of what FluxBB 2 should be, not necessarily the way it has to be. Like I said , the way it's heading I won't be using Flarum. But that doesn't entitle me, or anyone else, into pretending to take over the project. FluxBB 2.0 is Flarum. No big deal. I'll take a look and try to find an alternative. End of the story.

@Gil: of course Franz asked for feedback, and that's a really good thing if you ask me. My concern is not so much that people don't like to new way the project is turning, I don't really, either. What concerns me a bit is that a lot of negative feedback can be shortened to "don't like it so don't want it done" and I didn't expected that kind of behaviour here. Once again the answer to that stands in four letters: FORK ;-)

Last edited by Askelon (2015-03-24 23:15:53)

Offline

#58 2015-03-25 00:30:54

MMW
Member
Registered: 2013-03-17
Posts: 6

Re: 2.0: Joining forces with Flarum

First of all: Franz has done a great job in the past and definitely doesn't deserve being accused of treason and similar nonsense. He is trying to ensure an active development on FluxBBs future and that's good for all of us!

Furthermore, I feel, that this discussion goes into the wrong direction. The Ember-Approach is a huge technological change, but instead of criticizing the approach, we should all talk about possible advantages and drawbacks and whether they may be mitigated or even removed.

@Ember-App's size of about 300kB
The only thing that counts is the real transmitted size, meaning minified and gzipped. AFAIK basic ember is usually about 280kB, but gzipped (which it will be on any serious environment) its only about 90kB. I've no idea what the Ember-App itself adds to this, but 100kB is NOT much. That's the size of 1 medium-sized jpg (gzipp usually doesn't reduce the size of images, as they are already compressed). So before the size is discussed any further, we should first know the effective numbers (Question @Franz/Toby)

Furthermore, if these resources are cached right (far future cached), they are downloaded once (!)...until the next version is deployed and the resources change (which is probably just every few weeks). So data consumption on mobile phones is no argument either. On the contrary - IF done right, only the raw data (as JSON) is transmitted, while structures (html tags and so on) are transmitted only once. Again everything depends on the implementation, the technology itself does NOT determine whether more or less data is transmitted.


@Performance
JavaScript Apps MAY result in a better user experience, IF (again the magic word) done right. e.g. You're in a thread and click on something like "back to the overview". A good JavaScript App may instantly display the thread-overview, while the App is syncing this overview in the background and show possible new threads asap.

Another Example: Preloading threads. The App may already load the first posts of each thread, while you're on the overview-page. As the raw data of the first posts are only some strings, they will probably take less than 1-3 kB (image as loaded as soon as the user clicks on the post). This way navigating in the forum may be lightning fast. This may result in a better user experience, especially if the internet connection is unstable (e.g. reading the forum on the smartphone in the subway/train). => everything depends on the implementation, not the technology

@Extendibiliy
That's difficult to judge. On the one hand i fear, that complex changes could be harder, if the require extensive Ember.js & Laravel knowledge. On the other hand, small changes could be easier if backend and frontend are cleanly separated. I guess this completely depends on how everything is implemented.

@Integrating
Theoretically the application could be built so independently, that everything is isolated in one JavaScript Object (therefore no collision issues) and it may be integrated everywhere. That's an approach, I've recently used in a real-life project, that exists as integrated version (just specify a container-div and load the App into it) as well as standalone version.


@Conclusion
I feel that many people here suffer FUD and expect problems they have already experienced/heard/being warned about concerning this new client-side approach. I personally have no idea how FluxBB 2/Flarum will finally be and what issues it will suffer from. From what I've read from Franz until now, nothing is fixed yet. My point is: The technology itself is not the problem. Potential drawbacks are, but they may be avoided/mitigated if considered and handled (early enough). It all depends on the implementation, not the technology!

PS: I agree, that the current (alpha?) version of Flarum feels slow (compared to FluxBB) hmm

Offline

#59 2015-03-25 01:27:01

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

Re: 2.0: Joining forces with Flarum

@MMW

- Asset size: In addition to Ember, we're also including some other libraries like Ember Data and Moment.js, and we have our application code on top of that. Currently we're sitting at about 330 kB total for all JS/CSS, after minification and gzipping; I expect this will go up to about 400 kB with more features. At the same time, Ember 2.0, releasing in June, supposedly removes a lot of cruft/deprecations so might shave off some more filesize.

You're absolutely right about caching. I updated the Flarum demo yesterday to properly gzip + cache assets, so it should load much faster now.

- Performance: Your idea about instantly "going back to the overview" is already implemented! Go to a discussion on the demo and click the back button in the top-left corner and it'll snap back without needing to do any loading. I love your idea about preloading threads, something we'll keep in mind for the future.

- Extensibility: Yes, unfortunately complex changes will require both Ember.js & Laravel knowledge. But on the other hand, I think this has positives because it will encourage teamwork/collaboration when building extensions.

Last edited by tobscure (2015-03-25 01:28:47)

Offline

#60 2015-03-25 07:15:30

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

Re: 2.0: Joining forces with Flarum

minification and gzipping size only matters for bad connections to desktop computers and notebooks. For lower priced tablets and smartphones - which make most of the android devices out there - the amount of "unminified/not gzipped"-bytes is of interest: like said, a 1MB Jscript file is hogging a bit of the available RAM. While this will fade into darkness the next years (with cheap devices having 2GB RAM and more - of course 1+GB of this used by "service apps" tongue) it is still appearant these days.

@XAOS-Eric
While I surely would agree to some of your phrases, I am a bit of hmmm "shocked" by the tone of your posts: someone has to rise up and take the reins...
Why? Like stated in replies: if we do not like the potential future and are sure about the direction it takes _at_the_end_   we are able to fork.
But let's face the truth: some of us who are not ok with the _current_ plan wont follow "the one and only fork" - some will, some wont - that's life. And what will that mean? You will split the already small amount of "here and there patch submitters" into a again smaller portion. You might see 2-3 forks getting created and "improved" in the way their main-maintainers want. But do you think _one_ of these forks gets vulnerability-reports?

The only benefit "fluxbb" currently has to "forks" is: a "bigger" crowd of people doing things here and there - with Franz at the top on activity (and for 1.5 this isn't even that much - I understand, spare time coding etc. - and most of the things already "work"). It also has a bit of popularity, which makes it taken serious and therefor gets vulnerability-reports etc.

So joining "power" is a good idea - as it brings in "new air" to breath. We - as idea givers, code-reviewers, modders - should take this into consideration and see it as a chance to feedback what we think, we should not fight against the decision at all.

I gave my feedback: I want a board done on "classic methods" (oop php + sql) with sugar in the likes of "js adding convenience". Why? You are able to use your board without sugar (eg. if you are on "cheap-hardware-devices"-diet).
Advantage of "js-sugar": it reuses existing blocks created by the "php core" - just eg. with "flashing". So when styling you just have to adjust the templates and CSS. You only need to touch "js" if you want it to flash 2 times.
This would be even true if you used parts of a stateless html-approach ("html blocks" cacheable, "json-dataset" cacheable). So if you think of your core outputting a website as "html" or "json-data" or "xml" - it wont be that hard to replace "classic html delivery" with "classic html delivery + js-json-sugar".

Above is what I would like "my" fluxbb to target to. And yes, I am quite sure that Toby|tobscure would be of great help regarding designing such things. BUT I doubt that the idea fits well to his personal view on these things (which keeps motivation low then tongue).

bye
Ron

Offline

#61 2015-03-25 07:19:49

Askelon
Developer
From: Bretagne − France
Registered: 2010-06-09
Posts: 202
Website

Re: 2.0: Joining forces with Flarum

Tobby, just asking: why the choice of Ember JS specifically? When you think something like Backbone + Underscore weights less than 15 kb minified, it could have been a solution to the size issue. Backbone is also very much in the spirit of FluxBB, a simple basic tool with a lot of margin for adaptation.

Edit: 100% support on what Ron said above.

Last edited by Askelon (2015-03-25 07:28:46)

Offline

#62 2015-03-25 11:11:41

Starcom
Member
Registered: 2009-01-07
Posts: 9

Re: 2.0: Joining forces with Flarum

For me, I accept this decision but for what I've seen in Flarum demo :
- No toolbar in the editor (I suppose a plugin will add it)
- No smiley parser (I hope a plugin will add it)
- No (Sub)Categories
- ??? Templates

So sure, it's lite, modern and fast but at this time, I'm not sure that Flarum can be used for my MMORPG Guild forum for example. Even with a design work.

So I see that the Flarum project has some goals similars to FluxBB, but I think I will take a look to it and to possible FluxBB forks.

I hope these two projets will make a good hybrid system 50% FluxBB 50% Flarum.

Last edited by Starcom (2015-03-25 11:18:44)

Offline

#63 2015-03-25 11:58:55

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

Re: 2.0: Joining forces with Flarum

Askelon wrote:

Tobby, just asking: why the choice of Ember JS specifically? When you think something like Backbone + Underscore weights less than 15 kb minified, it could have been a solution to the size issue. Backbone is also very much in the spirit of FluxBB, a simple basic tool with a lot of margin for adaptation.

When I was first starting to build Flarum, I read a bunch of literature on the pros and cons on each JS framework. I was basically looking for something that would cut out boilerplate and make development fast and easy, while still providing a lot of flexibility and power. Relevant links:
http://ryantablada.com/post/why-i-chose-ember-js
http://eviltrout.com/2013/02/10/why-dis … berjs.html

Starcom wrote:

For me, I accept this decision but for what I've seen in Flarum demo :
- No toolbar in the editor (I suppose a plugin will add it)
- No smiley parser (I hope a plugin will add it)
- No (Sub)Categories
- ??? Templates

All on the roadmap! Early stages right now smile

Offline

#64 2015-03-25 12:18:38

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

Re: 2.0: Joining forces with Flarum

Thanks all for the continued feedback and discussion. There's no need for this to turn into a war, especially with personal attacks on Toby and I. That said, thanks to all those trying to keep the discussion on a proper level and calling others to be civilized. Let's all take a step back and try and sort this out in a civil manner.

Both approaches to a front-end have their own merits. Yes, FluxBB's lightweight HTML interface is fast and degradable, and there's value in that. Yes, Flarum's JavaScript approach bears a bit more weight but offers a better user experience on modern devices/connections, and there's value in that too. Yes, you are entitled to your own opinion, but don't pretend that yours is the only one. We've seen some of you in the FluxBB community value the former approach; meanwhile, there are hundreds of people following Flarum's development on GitHub with only positive things to say about it.

The back-end visions of FluxBB 2.0 and Flarum are essentially exactly the same. That is, the core of the software, the architecture, the database structures, and the philosophy of minimalism/extensibility, are all the same. That is the reason why it makes sense to merge these projects. This decision was made together with other core developers of the project.

I've de-facto been the one calling most of the shots in regards to the development and vision of FluxBB. That's not because I'm a dictator and want to push my opinion on everybody else, that's simply a fact born out of my contributing the most in terms of code. So in a way I've been forcing my vision on everybody for a while now, and that direction just changed a bit and received a new name. You're free to contribute to the future of FluxBB 2.0 over at http://discuss.flarum.org.

The point of contention here is about the front-end, not the back-end.

We've been having a productive conversation over at the Flarum Development Forum about how we can make this work for everyone. From the beginning, Flarum was built with a very flexible architecture. It is built in layers which are independent of one another. The Ember.js app is its own layer on top of the API, and it could easily be taken away and replaced with an alternative, more traditional web interface.

So here's the idea: instead of forking FluxBB and needlessly replicating that back-end, let's all team up and make an amazing forum software core/API. On top of that core, Toby and I will be continuing to build Flarum's Ember.js front-end. If that's not for you, why not get together, as a community, and build that traditional front-end package on top of the core at the same time?

Back to coding now... smile


fluxbb.de | develoPHP

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

Offline

#65 2015-03-25 16:43:54

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

Re: 2.0: Joining forces with Flarum

Franz wrote:

So here's the idea: instead of forking FluxBB and needlessly replicating that back-end, let's all team up and make an amazing forum software core/API. On top of that core, Toby and I will be continuing to build Flarum's Ember.js front-end. If that's not for you, why not get together, as a community, and build that traditional front-end package on top of the core at the same time?

Back to coding now... smile

One of the most sensible suggestions I've seen.

I'd like the option of choosing, that's be cool. Back-end all the same and if you want the front-end to be traditional forum you can have it or if you want a Flarum front-end you can have it.

Offline

#66 2015-03-25 17:08:54

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

Re: 2.0: Joining forces with Flarum

Franz wrote:

So here's the idea: instead of forking FluxBB and needlessly replicating that back-end, let's all team up and make an amazing forum software core/API. On top of that core, Toby and I will be continuing to build Flarum's Ember.js front-end. If that's not for you, why not get together, as a community, and build that traditional front-end package on top of the core at the same time?

Trying to say that FluxBB 2.0 is going to be Flarum just doesn't sit right right me. Just because you want to transition FluxBB to Flarum doesn't mean you should make users and developers of FluxBB 2.0 give up the FluxBB name. FluxBB is and will always be a php forum project, period, and I know you don't want to split the communities, but if someone wants to step up to the plate and continue working on the existing code in the FluxBB 2.0 core then you should let them. There is no need to add all that bloated js, like @Askelon mentioned, backbone matches the vision of FluxBB more closely. I even pushed 2 new models to the FluxBB 2.0 core yesterday one for plugins, and one for the themes database tables. The way I see it, FluxBB 2.0 is defiantly not ever going to be what Flarum is, and development on the existing code for it will continue.

Last edited by XAOS-Eric (2015-03-25 17:10:57)

Offline

#67 2015-03-25 17:22:07

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

Re: 2.0: Joining forces with Flarum

XAOS-Eric wrote:

if someone wants to step up to the plate and continue working on the existing code in the FluxBB 2.0 core then you should let them.

I wonder why nobody wanted to do so before this announcement. I was basically working on this on my own.


fluxbb.de | develoPHP

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

Offline

#68 2015-03-25 17:34:21

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

Re: 2.0: Joining forces with Flarum

Franz wrote:
XAOS-Eric wrote:

if someone wants to step up to the plate and continue working on the existing code in the FluxBB 2.0 core then you should let them.

I wonder why nobody wanted to do so before this announcement. I was basically working on this on my own.

I was doing this on my own time around my school work. I have a lot of changes that I'll be pushing within the next few days. I have mentioned before, that I'm able to step up and take over development of FluxBB if you don't have the time. I don't want to see the FluxBB project or name to die. I know you don't want to split the community, but I will not give up on FluxBB.

Offline

#69 2015-03-25 17:54:53

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

Re: 2.0: Joining forces with Flarum

I feel this thread is getting more and more aggressive, so I'm going to try and take a bit of a back seat now. I think Askelon has the best idea though, just create your own Fork of the current branch of FluxBB, that way there isn't (as) many problems.


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

Offline

#70 2015-03-25 18:21:25

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

Re: 2.0: Joining forces with Flarum

Franz wrote:

I wonder why nobody wanted to do so before this announcement. I was basically working on this on my own.

I do not like the idea of having a forum (which might be only a subfunctionality of a whole website) relying on a big framework - like Laravel. Of course you have many benefits on your dev-side: not reinventing the wheel for many things, but you also get the security flaws connected to a popular framework (and especially plugins/modules you want to use).

Discussing pro and cons of Frameworks is normally worth another thread but I am not in the mood to discuss that now (as other things are more important). I would like to see a fluxbb 1.5-based thing, maybe "rewritten" with some more modern approaches - now as the needs and requirements are clear.


I for myself like to have "some" script files in my "application"-folder (this time the "board software") and nothing more. Nothing stops a dev more than hundreds of files, no clue how things work there, what is overriding what and extending from X is done why?
I do not like to read "documentation", I like to understand things just by watching the code (selfspeaking naming convention helps a lot).

The "joining forces" might create something awesome - but "imho" it just moves another step further away from "1.5" - which is what _I_ would like to see continued.

But this does not mean that the development should not overhaul existing things by an "replacement". It is just that I myself do not like to develop for things I do not use (yet). So for "1.5" - if something does not work, I would patch it and pull-request that back to the main trunk. But starting the board "from the ground up" with no knowledge about security state, potential SQL dead locks or whatever - I wont use that on my websites, so I wont "dev" on it.

What I wanted to express with aboves text block: evolving a software project (improving existing code) is what I would like to see here, not revolution (making existing things better by completely rewriting it).

Coming back to "convenience" this is unproblematic because it _adds_ to something, not _replaces_ something.

Nonetheless: feel free to do whatever you want, it wont be the worst decision in all cases - maybe not the best for each of us, but for some.
Maybe we are just a bit too stubborn to see that times are changing - but for me I still stand behind the things I wrote above (file size matters, try to use the LCD regarding requirements on the userside - except "text only" variants).


bye
Ron

Offline

#71 2015-03-25 18:45:46

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

Re: 2.0: Joining forces with Flarum

Franz wrote:
XAOS-Eric wrote:

if someone wants to step up to the plate and continue working on the existing code in the FluxBB 2.0 core then you should let them.

I wonder why nobody wanted to do so before this announcement. I was basically working on this on my own.


Didn't see this post before. I don't know anything about Laravel, otherwise I would have. sad


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

Offline

#72 2015-03-25 18:58:30

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

Re: 2.0: Joining forces with Flarum

GWR wrote:
Franz wrote:

I wonder why nobody wanted to do so before this announcement. I was basically working on this on my own.

I do not like the idea of having a forum (which might be only a subfunctionality of a whole website) relying on a big framework - like Laravel. Of course you have many benefits on your dev-side: not reinventing the wheel for many things, but you also get the security flaws connected to a popular framework (and especially plugins/modules you want to use).

Discussing pro and cons of Frameworks is normally worth another thread but I am not in the mood to discuss that now (as other things are more important). I would like to see a fluxbb 1.5-based thing, maybe "rewritten" with some more modern approaches - now as the needs and requirements are clear.

Rewriting FluxBB 1.5 with a more modern approach is defiantly doable. FluxBB is our community, and I will fight tooth an nail to save it if need be. FluxBB 2.0 will live on even if it means @Franz has to split the community and step down to focus on Flarum. Granted there may not be as many FluxBB developers as there were in years past, but that won't stop me from fighting to keep the FluxBB name and project alive. That being said, I also have ideas on how we can get the community more involved on the FluxBB forums and improve the project at the same time.

Offline

#73 2015-03-25 21:32:51

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

Re: 2.0: Joining forces with Flarum

Regardless of future decisions you might post your "ideas on how we can get the community more involved".

I ask you to step back from your current "revoluzzer" tone. I assume even if most of us (posting in this thread) are not agreeing to the OP content, we wont like to be generalized to your "fight tooth and nail".
I of course accept that people will do many things to keep their beloved projects alive - but with todays "social coding" platforms like github, it is a "no-brainer" to take feature-commit X from fork Y to your own fork Z. It is Open Source ... you can see what they change, you can reuse it (according to the licence).

If you want to keep the "name", then why? To get "fame"? I myself like the _product_ not the name - I used punBB before and fluxbb was the logical consequence when dev stopped / stalled.
So __if__ nobody would develop "fluxbb" (1.5) further, and others do - I will watch who's fork is the most active one - and check that fork for "security"-patches. And within the next year(s) I would check if I need to replace the board or if other options aroused.

No fight, no big dilemma - just pragmatism.


bye
Ron

Offline

#74 2015-03-25 21:44:59

cyberman
Member
From: Germany
Registered: 2010-01-11
Posts: 289
Website

Re: 2.0: Joining forces with Flarum

Franz wrote:

If that's not for you, why not get together, as a community, and build that traditional front-end package on top of the core at the same time?

+1

Offline

#75 2015-03-25 23:24:01

Askelon
Developer
From: Bretagne − France
Registered: 2010-06-09
Posts: 202
Website

Re: 2.0: Joining forces with Flarum

... Wow.

GWR wrote:

I ask you to step back from your current "revoluzzer" tone. I assume even if most of us (posting in this thread) are not agreeing to the OP content, we wont like to be generalized to your "fight tooth and nail".

I second that. We get that you want to "take over", XAOS-Eric, that's the fifth time you've said this in three pages. Franz was pretty clear: FluxBB 2.0 is Flarum. Get over it. And no, the chair does not seem to be free to take over. Period. You should follow Ron's advice and stop embarrassing yourself any further.



Franz wrote:

If that's not for you, why not get together, as a community, and build that traditional front-end package on top of the core at the same time?

Now I do like that idea. I'm still concerned about the required Laravel knowledge to build plugins, but I'm in for a joined, powerfull core and various frontend by the comminuties. Might event be the occasion to make a Backbone-powered frontend. Even though I don't like so much the frontend choice, I have confidence in the backend work smile

Offline

Board footer

Powered by FluxBB