As a mini update from me again: I have not been able to contribute code in some time due to work and college. However I continue to review PRs, comment on issues and partake in the forums and Discord. On the bright side though my "SameSite" Cookie PR did get merged since I last posted here.
Dev Diary: Beta 14
Happy to see progress reports still.
Looking forward to the frontend rewrite. Can i ask why it's being rewritten?
Last i checked when i was looking through the source code and structure of the whole system to see how hackable it was ( i want to do significant changes for a few forums ), the front end portion of the system was quite complex and hard to work on, to the point where i'd skip over flarum as a future platform..
... i'm wondering, would the new frontend be easier to customize.. and/or, does it provide any other benefits to the end user/developer? 
neptronix It's being re-built because it's currently on Mithril 0.2, we are upgrading to Mithril 2.0 and also upgrading to Typescript (although extension devs can still use JS) so that we are are up with the latest version of Mithril on stable launch as well as have the more stable, less likely to break Typescript. There are also some discussions around moving some of the files around to make it a little bit more understandable.
neptronix the front end portion of the system was quite complex and hard to work on, to the point where i'd skip over flarum as a future platform..
In addition to what tankerkiller125 described, would you be interested / willing to share some of your concerns or frustrations with our current frontend system and how it's extended? Our vision of Flarum is that it is as much a framework for incredible extensions as it is a software product, so extensibility and developer-friendliness are our top priorities. If there's something we can do (better helper/utils, better layout, better documentation, better structure, etc) to make your (and other developers) experiences better, it's definitely something we want to explore.
I see, that's a big transition!
askvortsov would you be interested / willing to share some of your concerns or frustrations with our current frontend system and how it's extended?
I have to be honest and say i haven't investigated it for a long time. But from what i remember, there's many more layers of abstraction in your system versus what i'm used to working with ( phpbb ), so to me, it's quite difficult to understand what's going on and trace execution. When i asked how y'all trace execution from start to finish, i didn't get an answer, and was discouraged from doing so.
I want to do some very extensive changes, like completely change how categories are displayed, especially the list, so i'd have to understand how the system works from the bottom to top.
From a developer perspective, documentation would be the #1 thing to focus on. The lowest level of abstraction possible would make for the easiest development job too.
Can we please have a better search function in the next release like Advanced Searched?
And also, search option within discussion would be nice too.
- Edited
HD3D search improvements are planned, some for stable, some not.
Some progress is being made in this direction: flarum/core2104
4 days later
My expectation is have a decent translation system, i'm tired of translate and translate again yaml files on each Flarum/Plugins update.
Awesome, Would be great if the flexibility of code splitting is added in rewrite. That would help flarum load faster even when a lot of heavy extensions are enabled. Must for SPA's to improve initial load times I feel.
Zeokat Translations will probably always be done via the YAML files, however I do believe that at least one person found a way to use a web application to build these translation files for you. I'll have to see if I can find that post somewhere.
- Edited
th30n3 This will most likely never going to be possible. Even if we did use code splitting & added a way for extensions to specify which bundles they need (already complicated), they'd most likely require parts that have been split. Extensions can use whatever components they want in the forum side in any page, so I feel like all the JS bundles would be loaded anyway.
Would I like code splitting? Yes. Do I think it's feasible? Perhaps, but it would require a lot of thought going into it, and you can never guess how/what extensions are going to do.
- Edited
datitisev Thanks for putting a thought on this. You are right, there is a lot of complexity. It definitely requires a lot of thinking if at all to be implemented. I had put a thought on this once, one way this could be done is accept additional parameter to whether compact specifed js or just copy to output folder.
(new Extend\Frontend('forum'))
->js(__DIR__ . '/js/dist/Home.js', copyToOutputFolder : true)
and extensions may use mithril route onmatch loading
m.route(document.body, "/", {
"/": {
onmatch: function() {
return load("Home.js")
}, },})
But when extensions start using this, they may have to use unique names for these js files so that names do not clash between extensions. One solution is to force extension name prefixing to file names ...
Again, just a vague thought. Surely there is a lot of complexity that will go in. I have not even considered webpack here. But in long run, code splitting may be way to go.
11 days later
Last Friday the progress meeting for beta 14 was held. I think overall the general opinion is that we are well on our way to release our planned change at our deadline.
In the meantime many other activities take place, but not so that it impacts our targeted stable. We are looking at our current website and are planning to talk about marketing in general. We are answering requests for information from companies as well as development firms interested in adopting Flarum.
Under these circumstances, we are extremely appreciative of the increasing attention Flarum gets.
my wishlist
- 404 url handling feature
- related posts + custom related post
- Edited
Hari I understand everyone's hopes to see their personal favorite features added to stable. We've also made a decision to underpromise and overdeliver.
No new features will be added to core before stable, because we need to focus on stabilizing the extension api. This will reduce the likelihood of extensions breaking on new releases after stable.
Our goal is to create an extensible forum framework allowing extensions to shape it to your every need.
That your features are possible with an extension is very likely, so do keep an eye out for that.
We call it only a forum, but the features are not over.
4 days later
- Edited
For those of you who missed it, last weekend I decided to step down from being an active core developer in order to focus completely on leading Flarum to its future.
luceos I have stepped down as active core contributor to focus on my other duties in the project. For a while I haven't been able to live up to my own expectations of the core position.
The new badge has replaced a badge which holds significant meaning and well deserved respect. Especially to me, I literally pursued the position for a very long time. But it's time to take charge of the flarum future as my sole responsibility instead. Something I have been doing since the foundation adopted the software, but with stable on our irises, it's now an even more pressing priority.
7 days later
- Edited
It's time for an update.
What I did:
- For the past few weeks I've been working on a redo of our flarum.org website. Something that I'm hoping we can deploy somewhere before the stable release. The day before yesterday I moved the docs out of our main domain (flarum.org/docs) to its own subdomain (https://docs.flarum.org) to improve SEO of our main domain on non technical terminology and to prepare for the new website by simplifying the deployment script.
- With more time on my hands I've been looking at our strategic positioning again. So that we're not completely unprepared for whatever hits us around and after stable.
- Respond to inquiries from differently sized companies, including a multi billion enterprise from Australia. Interest in Flarum is increasing, that much is clear
!
About development:
The core team has been extremely active. A great pace has been set by the core team to rewrite the frontend. It requires a lot of discussion; pull requests are openly and privately scrutinized in order to achieve the best results.
I do think, seeing how much work is still left ahead of us, that our targeted deadline of August might need to be pushed back slightly in order to get to a stable and reliable fourteenth beta. In addition we'd hate to break extensions twice in rapid succession. I know this is disappointing, seeing that beta 14 already was given one month of extra time. Sometimes we need to lose a battle to win the war. In software development you sometimes have to sacrifice delivery times, to guarantee the best product. Especially because we know you love Flarum, therefor to us the only viable release is a great one!
At the end of this week, we'll know for sure whether delaying beta 14 to September is necessary.
We will keep you up to date about any news related to our project and beta 14 specifically. Thanks for your patience and understanding.
10 days later
Awesome to hear, Keep up the great work, guys!