The future of Fomantic as v3.0

[y0hami]

We have a ROADMAP now 🎉

---

We created Fomantic-UI (FUI) to continue the active development of Semantic-UI (SUI) until development on the main project could continue, that was 199 days ago (as of writing this) and the last SUI release 2 months ago (as of writing this). SUI has shipped 4 releases since then and we have shipped 13. That being said you can probably see that development has drastically slowed down over time on the main repository which brings me to my next point.

When we created the project we stated that FUI has the

intent to be merged back into the master repository once active development can restart

now with the following changes/plans which are listed in this issue you will get a clear understanding why we have changed our minds and why this can benefit you and the FUI project as a platform.

To be clear merging back into SUI is still our intention, read this comment for more info

Before I get started feel free to leave comments and suggestions, remember this is a community fork and we want as much input as we can get to make this a truly community built platform.

---

New Documentation Website

This has been on the todo list for awhile now but was too big of a task to do for a single release so 3.0 is a perfect time to do this and especially with all the new changes.

Currently we are still investigating what software we want to use and how we want to build the site (statically generated etc.) but we do have a few requirements

• Must be easy to edit
• Must be easy for new contributors
• Must be quick to start and build
• Must be able to render/compile large pages

New Build Process

We have been talking about this for awhile because the current system is too bulky for what we want. Also when rewriting it we can investigate new technology and processes which might make the build system more efficient and faster.

We are still looking to how we want to do this but we do have a few requirements

• Must be able to compile LESS to CSS
• Must be able to bundle CSS and JavaScript
• Must be able to customize it
• Must be quick
• Must be small and not bulky

Theme Builder & Web Store

Starting off in the paragraphs above you may have noticed I mention the word platform a lot, this is because for 2019 and 3.0 we are pushing to make more then just the CSS/JS framework your familiar of. We are planning to start building 2 new websites first a theme builder to make it easier to create themes since the current method just isn't good enough. Second is a community powered "store" which allows users to download themes, templates, plugins etc. When we get to making the store the one promise I will keep is that all content will be free and won't cost a penny!

I am taking name suggestions for the web store because I don't want to call it a store.

Project Structure

This change will be big and will require other items on this list to be complete for we can 100% do this. We want to convert this repository (fomantic/Fomantic-UI) into a centralized location for all "modules". Basically that means making a directory called packages which will contain all components as individual npm packages and also have a few core packages e.g.

repo/
  packages/
    utils/
    core/
    css/
    components/
      button/
      container/
      grid/
      icons/
      input/
      form/
      dropdown/
      calendar/
      ...

On npm we will have a new org called fomantic which all packages will be published under. The npm naming will be like the following

@fomantic/core  - The core package with all components (basically the current repo)
@fomantic/css   - The CSS only distribution
@fomantic/utils - A set of core functions used throughout the library
@fomantic/component/button    - The button component
@fomantic/component/grid      - The grid component
@fomantic/component/icon      - The icon component
@fomantic/component/form      - The form component
@fomantic/component/dropdown  - The dropdown component
@fomantic/component/calendar  - The calendar component
...

All components will contain all the required assets and resources to work i.e. all LESS and JavaScript files and any image/font assets.

Now you might be asking how does this benefit the development, well this will make all components module therefore in theory they should be decoupled. This can help with development because it makes it easier to manage each components changes and make it easy for new contributors to make changes because they can easily find the code related to components. This also solves a problem where some components depend on others by allow us to use npm to manage the dependencies and now have to have duplicate files in each separate component to distribute them separately.

Another big benefit to this is it makes it really easy to only include the components you need.

You may have a few questions relating to versioning and changelogs well we haven't come to a decision on how we will do that but a changelog in each package probably to keep track of changes and then a larger changelog in the to act as a library changelog like the current one. Versioning is a bit different, maybe versioning each component and then when releasing new library versions we could change the "mega" version to the total calculated via all component changes using semver. If you have any suggestions feel free to too.

ES6 & JS Rewrite

So this is a big task to undertake but all current contributors are for it.

We want to rewrite all the JavaScript modules to remove the dependency on jQuery and to clear up the syntax and complexity to make it easier for new contributors. We also want to centralize all the common functions used throughout the library. We are currently going to make a module called @fomantic/utils which will hold all the common functions which all the individual components can depend on since the new structure will allow that.

As for the rewrite, it will be ES6 and classes, maybe something to produce code like this?

import { Dropdown } from '@fomantic/core';

const countryDropdown = new Dropdown('#countryDropdown');

countryDropdown.on('change', (value) => {
  console.log('Country Changed', value);
});

countryDropdown.select('gb');

Why classes? Well making the modules classes will make the library easier use and understand and will modernize the framework by using new JavaScript features and standards.

Again we are open to feedback.

Tests tests tests

From the start of making FUI we have been trying to figure out how to implement CI/CD and tests because we believe this is the best way to ship code fast but while staying efficient. Near the start of FUI we partnered with BrowserStack to help test features and bugs which we still use and is amazing but with that partnership we also got automated testing which we have yet to get a chance to look into and that would be awesome but we need a way to test the components in a browser which is our biggest problem. We first agreed to making pages which contained all the components which we could load in something like nightmare but that soon became a large task.

What we want

• Full CI/CD process
• Testing of all JavaScript components
• Testing of all CSS components (checking they don't change a components style when they shouldn't, maybe something like percy)

---

I hope this helps you understand why we have made the decision to branch away from SUI and start moving towards our own plans. We are truly trying to make a library which works for everyone and with the restrictions of being compliant with the SUI repository this goal was no longer possible.

Again if you have any feedback you may have from other requests or suggestions feel free we are open to all 😃

We are also available on our discord throughout most of the day (EU timezone) so if you want come and chat!

---

Additional v3 issues:

• v3 theming proposal
• The discussion of jQuery & it's relevance to v3

---

We are running a survey for v3 research, if you have 5 minutes to spare to fill it in we would be much appreciated! https://www.surveymonkey.co.uk/r/398M9YJ (Survey is now closed)

[Atulin]

Is a rewrite of the theming system (to something more sane, like, say [buttons, headers, ...] -> main -> [dark, light, ...], maybe with a reduction to the number of variables too) planned, or is the current system so ingrained into FUI that only a separate tool can help?

Other than that, super excited for FUI dropping the dead weight SUI corpse off, especially the removal of jQ dependency.

[lubber-de]

@Atulin While working on #261, rethinking the themeing logic as well as reducing the amount of variables is definately on the roadmap.

[etshy]

This seems really good !
The Jquery dep removal is really good. I guess with this, the library could work in project that don't use jQuery but other things (like Angular, React, Vue, etc.) easier.

Excited about all that. 👍

[donaggio]

About jQuery dependency removal: while in general I think having the less dependencies the better, I'm a little worried about it this time!
It happens I started using FUI on a legacy website gradually substituting as much of its custom styling with FUI components as possible and it's still an ongoing process. This legacy platform heavily relies on jQuery, so having it as a dependancy for FUI is not a downside at all for me.
Does removing jQuery as a FUI dependency mean end users will be forced to rewrite all FUI-related js logic?
For example will we need to replace code like this:

$('.ui.dropdown').dropdown();

with something else?

Or the proposed changes will impact the internal workings of FUI exclusively and a jQuery compatibility layer will be maintained (along with others, like the mentioned Angular, React, Vue, etc.)?

[lubber-de]

@donaggio We could think of some kind of adapter-system where you can choose if DOM manipulation should be done by familiar old jquery function names, internal/native ES6 functions or even a new virtualDOM system like for example https://mithril.js.org/ uses.
That would probably still mean to always use wrapper-functions. 🤔
We have to discuss this further. There are always pros and cons. That`s why we will hear your voice 🙂

[y0hami]

@donaggio With 3.0 we will be rewriting the JS modules into a more class based approach which I mention above. This will mean that you will need to rewrite current code. This is a big downfall but at I am sure we an look into maybe making something like @fomantic/v2-pollyfill which makes some sort of bridge/wrapper to the new method of creating the components.

As for the jQuery removal I don't see why this would affect your site. If your site depends on jQuery but FUI doesn't, does that really matter? I do think we could do something like what @lubber-de has mentioned allow the user to define what DOM manipulation library to use. I think this could be quite easy since @fomantic/utils will basically just be our own library for DOM manipulation so making a way to plug different libraries could be something we look into.

[ColinFrick]

I think even providing a jQuery wrapper (f.e. @fomantic/jquery) which provides a backward compatible API would be possible.
Furthermore this doesn't mean we are not working on the 2.x any more.

[donaggio]

@hammy2899

As for the jQuery removal I don't see why this would affect your site. If your site depends on jQuery but FUI doesn't, does that really matter?

No it certainly doesn't. I'm concerned with those parts of FUI which exposes its functionalities and are currently all jQuery stuff. Changing how they work, for web developers could mean having to rewrite lot of code which is difficult to distinguish from non-FUI related code - having to resort on searching for all the occurrences of ".dropdown(" and all other FUI jQuery functions can be a real PIA ...

I do think we could do something like what @lubber-de has mentioned allow the user to define what DOM manipulation library to use. I think this could be quite easy since @fomantic/utils will basically just be our own library for DOM manipulation so making a way to plug different libraries could be something we look into.

It just could be a temporary solution, a jQuery compatibility layer which at the same time alerts you about which code needs to be rewritten as it-will-be-deprecated-soon(TM)

[y0hami]

@donaggio I think we may do something like what @ColinFrick and I mentioned a jQuery pollyfill which allow you to use the v2 syntax and we could maybe warn in the console with a stacktrace of what is using legacy code.

[donaggio]

@hammy2899 Great! That would provide an easy migration path from 2.x to 3.x retaining full compatibility while we switch from the old syntax to the new one.

[singhda8]

Does the roadmap include a plan for Angular support? I'm using the ng2-semantic-ui package for now but I worry about ongoing support with newer releases of FUI.

[Atulin]

@singhda8 Semantic-Org/Semantic-UI#6693
Based on this, and on SUI for React, I believe the way to go is forking as needed. With the planned removal of jQuery, I think FUI wants to be library-agnostic, using pure JS. Which is the way to go, if you ask me.

[princeandrew01]

@hammy2899 I am very excited for this and I am sorry the intent to merge was never achieved.

[romaninsh]

Great decision guys! Will support you on your journey, let me know if any back-end / DB work is needed.

In terms of JS, me / ATK would be OK with "Vue" but not something more "heavyweight". Too much of a constraint. Besides React/Angular already have their own projects, they can simply switch from SUI to FUI if they wish.

[YamiOdymel]

I'm also creating an UI Component library, and I'm not gonna lie, but front end with unit testing is harder than learning C language.

You will waste more time on creating unit tests, and once you changed the CSS/Style, you will have to change the unit test too. Everything will be like a chain and you will have more jobs and code to change: xkcd: Automation

My stupid idea to compromise with this issue is to create a test page (with Pug) for each of the components (a little bit like Kitchen Sink of Semantic UI)

with a customized page generator (I made it with Golang in this example), it will generate a component test page with an index list, and I can debug or make sure it looks okay with the human eye (yes, I tested the components on my own, at least it's simple).

If you are trying to test the JavaScript modules... I think it's fine since you are testing with the behaviors of them. But if you want to test the CSS styles... it's might be really- hard.

[douglasg14b]

Good stuff Hammy, I'm beyond thrilled that the fork has been so successful. It's relieving to know that the framework I know and love is well and alive. 10/10, bang up job.

Putting aside the technical discussion for a more community/engagement/image one:

When this fork started I imagined this would be the case, the more development that happens here the more it will diverge from the original project. And eventually it won't be possible to easily merge back without completely taking over Semantic UI, or without making significant compromises on both ends. Which puts this project in a pickle, as it lives under the shadow of Semantic UI, which can be smothering the longer it sits idle.

The biggest hurdle I see facing Fomantic is community growth and use. Semantic UI users won't know about Fomantic, and are likely to move onto other frameworks instead once they get the "dead project" feeling. Hell, most of my colleagues that loved semantic have moved on over the last couple years because they don't want to get stuck with a deprecated/dead framework. I've told them about Fomantic, but it's too late now, they are burnt and invested in something else, only a few very passionate devs make the effort to invest back into using Fomantic.

So, a few questions (directed at anyone that cares to answer):

• How do you plan on tackling this to show these other libraries/frameworks/developers that Semantic UI IS well and alive, just under a different flag?
  • Even Google still thinks Fomantic UI is a typo and redirects to Semantic UI which means it's even harder to discover.
• How does Fomantic grow it's community and user base under the shadow/growing stigma of Semantic UI?
• Ideas for letting other large projects/component libraries know about Fomantic?
  • Essentially community engagement activity outside of this repo, to "spread the word" and provide some support/info to other libraries that rely on semantic UI.
  • Idea: Chatting with and seeing what some of these library maintainers would need to transition to Fomantic, if they do. This could help drive some of the projects development to assist other libraries and projects to switch over. Which is an effective way to spread the project.

[Bradley-H]

For whatever it maybe worth, could you also redo some of the typography? Specifically with the floats, instead of "float left" or whatever, can we just do "left" or "center"?

And I might be asking for much, but one thing I would like to see in the future is a one line use code to initalize all JS componants. It's what Materialize-css does and I think it would do wounders for the project

https://materializecss.com/auto-init.html

[QWp6t]

I suppose there's still no interest in using PostCSS or Sass, right? You guys are sticking with Less?

[y0hami]

@singhda8 We currently have no plans for a FUI Angular implementation. That being said once v3 is released I think making some "plugins" for such frameworks like React, Angular, Vue etc. would be a good idea.

@YamiOdymel Yes I agree unit testing UI will be hard and pointless with the amount of work it would take, thats why we want to make a repo with examples of each component in near to all variations so we can check that they look as intended. Looking over all these examples by human eye would be stupid so thats why we are looking into something like percy. Thanks for your info 🙂

@douglasg14b As said when I started the fork I had the intent to merge back but in the back of my mind I always knew that if it grew enough it would out grow SUI. Weirdly enough that's what I wanted, I knew that if FUI grew enough and the community wanted to back it we could then rebuild the project into one which we all liked. I see SUI as a project people use because its easy to use and looks great out of the box but I want to make FUI a project which is community focused and driven. Once a project is community driven users don't just use it because its easy and looks good, they use it because they feel like they are apart of it and they have a say in what happens. This can be beneficial for both parties. It helps the project grow because the users are engaged and they start contributing and it also helps the users because they get what they want out of it.

That being said I am astonished with the feedback and growth FUI has had already, the project is really young compared to others and yet so many people want to help 😊. So far there hasn't been any advertising apart from a few issues on SUI and just word of mouth and maybe a few reddit posts. We (contributing team) had a small discussion about advertising and we agreed to putting a few £/$/€ in a month to do some social media advertising etc. which should get a couple thousand/million views over a few months. The Google search problem will fix itself over time with more articles etc. currently there is nothing we can really do.

Your point about letting other libraries/frameworks/developers know about FUI could be beneficial and I think we should start looking into that. atk4 have already moved over to FUI (thanks @romaninsh 😉). I think word of mouth will have to do for now for letting developers know but a reddit post or articles on some dev websites wont do any harm. However I do think we should "partner" with some other frameworks/libraries to assist them with moving over to FUI from SUI.

The stigma of SUI is defiantly growing and I can feel it myself. I think v3 will be a big help with this as we will be rewriting a lot of the code base and will be generally "modernizing" the library which should help since it will give it a new slate. That being said this won't be happening for a while so people will be seeing FUI and SUI and instantly assume FUI is bad because of the current SUI state but that is just natural. I think if people really do care about using SUI/FUI they will see the FUI repo is very active and will see that it is heading in a complete different direction compared to SUI.

---

Sorry for late responses 🙂

[y0hami]

@Jncocontrol @QWp6t We aren't rewrtting any CSS/LESS. I think the most we will do is just tidy it up. That being said I don't think we will be changing any of the semantics maybe just a couple. The float left/right classes makes more sense then left/right. If you have a class of left segment does that mean the segment is floated left or the text is aligned to the left? Where as float left segment makes more sense. The most we can improve is making it left floating segment or left aligned segment etc.

[wrighta16]

I've only recently found FUI after adopting SUI in summer 2018. I switched to SUI after having first adopted Framework7 then moving to jQuery Mobile then, due to it stalling, switched to SUI. So, boy am I glad to see FUI emerging with a healthy community!
jQM documented changes in coming, proposed releases, so where features were being depreciated/retired, etc. That's fine when developing new code, as you just avoid using anything without a future. Having to have a conversion code adaptor is bound to slow the platform but could just be used as a transition arrangement to aid migration from V2 to V3.
I use FUI/SUI along with Codeigniter for backend db stuff. I just incorporate the full, compiled 'dist' version of SUI code.
I can't see me dropping jQuery from my overall application framework, so removing from FUI, whilst may have advantages internally, it's not a major factor for me.
Having an online theme builder would be good. jQM had its 'themeroller' that did a job, although it had limitations!
My preference would be to have a LESS to CSS run-time compilation setup, akin to some Joomla themes. So it detects if changes are made to LESS and regenerates the CSS. From looking at install options, all SUI/FUI appears to be compiled on installation but haven't had enough time on it.
In any case, I'll follow with interest... Thanks, All.

[douglasg14b]

@IsaakGroepT

I'd like to correct a couple things, at least from how I see it. FUI was forked from SUI not because of SUI slowdown by itself, but because the SUI owner/maintainer would not let the community become involved with it's upkeep and development. It was essentially a one-man show, and when that one person is not available the whole thing grinds to a halt.

FUI on the other hand is not maintained by essentially a single person, with the community being unable to contribute. There are more individuals involved as maintainers who have the ability to manage issues and pull requests. Helping to ensure it doesn't meet the same fate as SUI, where the community is constantly trying to add fixes and making issues, but even pull request sit idle. You had issues and pull request being auto-closed by a bot for being "inactive", despite the community being very active, but there wasn't someone there to manage the repo.

[domenkozar]

This looks great! Please setup http://opencollective.com so we can make this project sustainable on the long run.

[Bradley-H]

This looks great! Please setup http://opencollective.com so we can make this project sustainable on the long run.

I think a more ideal place would be Patreon

[lubber-de]

Having said that - does anyone have any idea why there have been no new releases since June?

2.9.0 is in the works with lots of features....already available in the nightly npm/cdn build
keep an eye on the develop branch ;)

[dorner]

I can definitely see lots of movement - I'm just wondering why there has been no official (non-nightly) release for so long. Is there a particular milestone that's being aimed for?

[lubber-de]

2.9.0 will include slightly breaking changes and also deserves bigger changes/new features, which we have collected for quite some time.
I believe, once 2.9.0 gets stable, further 2.9.x releases will delivered more often again.
thb i am thankful to all people actually using/betatesting the nightly branch, so we were already able to determine and fix bugs before they got officially released. The docs are getting more and more updates for 2.9.0 theses days, so we are trying our best to get it done asap.

[dorner]

Thanks for the update!

[alexnicolaisen]

After SUI had been "dead" for years, I really loved that FUI rose out of the ashes and the development started again!! As everyone else say here, I use FUI for the ease of use, and it's already everything I need....without a large V3 update/change.

I love to read that 2.9 is on its way <3 Please keep up the excellent work you are doing!

[JobberRT]

For my opinion, i suggest fui's document needs a big update, not only migrate them to something more controllable or mangnable, but please also add more description, like bootstrap5 did. For example:

• I can easily found the differences between "align-item" and "justify-content" in bs5, but hardly to find "aligned center" and "aligned".
• in Grid Introduction, negative space is introduced in very first part of the document: grids, but only explained later on the document: gutters

Also, please change class name to XXX_YYY, don't use XXX(whitespace)YYY, it's very confusing to read(is it XXX YYY a single class or XXX is a class and YYY is another class)?

For better growing of fui/sui, and for beginer to easily understand, please update to a good & complete & easy-to-understand & logic-clear document.

[donaggio]

@jobber2955 here are my two cents: classes names as they are now are what makes FUI so ... "semantic" (FUI was known as Semantic UI at the beginning) and, beside, changing them would be frankly absurd at this point, braking compatibility with almost everything and an enormous undertaking to gain very little in return.

[Atulin]

@jobber2955 big red button is the thing that attracted me to SUI and later to FUI, I'm willing to bet many others also prefer it over lg_btn_red or whatever other atrocity

[JobberRT]

@donaggio @Atulin For me both naming format are pretty good, xx(whitespace)yy is more human readble but xx_yy is more clear. I think if FUI can add more specify document to classes & classes behavior or something else, this naming problem won't be a problem.

To be honest, i presonally prefer large red button than lg btn red, it's more straght forward than those shorthand naming, but sometime causing me confused with large red button and large(this also affect form) + red button, Hope a better & specify & complete & clear document will come out at 3.0

[lubber-de]

@jobber2955 A technical reason for the current usage of xx yy is simple class inheritance.
Let's stay at your large red button example.

• A Button in general has some settinsg independent of the color or size. For example border-radius
• A red button is red, regardless of the size
• A large button is large regardless of the color

So

.ui.button {
	border-radius: 5px;
}
.ui.red.button {
	background: red;
}
.ui.large.button {
	font-size: 3em;
}

When we would use the xx_yy approach, we would have to make sure that all possible combinations are covered.

.ui_large_button,
.ui_large_red_button,
.ui_red_button,
.ui_button {
	border-radius: 5px;
}
.ui_large_red_button,
.ui_red_button {
	background: red;
}
.ui_large_red_button,
.ui_large_button {
	font-size: 3em;
}

Now think of all the colors, sizes, variants we have for all those components .... 😉

And, before you reply, i dont like the other approach with bloated css classes to gain the same effect like

ui_button ui_large_button ui_large_red_button

I don't think this is more readable and, as the others pointed out, you still have to rewrite your whole codebase anyway without really having any benefit.

[JobberRT]

@lubber-de OHHHHH!!!! I UNDERSTAND NOW!!!! What a smart and simple method! WOW! I haven't thought about class inheritance issues! This is a very effective trick, now i get it, thanks for explaning!!!!

[jasrusable]

I know I said this awhile ago but I want to reiterate it (and leave a 👍🏻 if you agree!), there is a place in this world for an easy-to-use, feature-rich, lightweight CSS UI framework.

You don't need to (re)design this project to fit massive enterprise projects. There is something to be said for adding a single line of CSS and a single line of JS to your web app in order to gain access to a rich library of UI/styling/controls.

If you want to have native support for React/Vue/Blazor/whatever, that's all well and good, but those should be separate projects/forks of this. Keep this project simple. You have something really special here, and IMO your control/element library is way better and way easier to use than the alternatives out there (Material/Bootstrap/etc).

Double down on what is at the core of this project, what makes it unique and awesome: The fact that it's a simple, easy to use UI library. Forget about industry trends and JS frameworks, there will always be a place in this world for projects like this.

We ❤️ you guys and we ❤️ this project! Please keep it going!

+1 to this. And to add to some of this, I think it would be great to have a Fomantic fork of https://github.com/Semantic-Org/Semantic-UI-React that keeps up-to-date and is possibly maintained/supported by Fomantic. Perhaps the Semantic-UI-React team would consider tracking Fomantic going forward seeing as Semantic is dead. @levithomason @layershifter?

Also see:

• Vision for SUIR? Semantic-Org/Semantic-UI-React#4230
• Questions regarding the future of SUIR Semantic-Org/Semantic-UI-React#4163

PS: Thanks all for the great work!

[y0hami]

@jasrusable Regarding SUIR they've stated in the past that they wanted to keep it tied to SUI as that is the project after all which I understand. Unfortunately we just don't have the capacity to undertake another fork like FUIR so that will not happen (continue reading).

Regarding everything else what people have been saying, WE HEAR YOU don't worry like I said FUI isn't going anywhere and we want to keep this a community effort which is why we bring plans forward for comments so don't think we're going to change everything in a direction the community doesn't want. In the coming weeks I'm going to investigate some possible ways to move away from jQuery but maintain the exact current library. I am also going to look into rebuilding the build system to move to a more modern way of doing things so we can move away from legacy libraries and code and make it easier for us to maintain it but also make it easier for people to integrate FUI into their projects. If you've been following the project you can see there is lots of issues when it comes to installing and building FUI into projects especially modern frameworks. Once these things are done I still want to move forward with a "soft v3" and improve modules and pull them apart into a more meaningful way to develop aka make common modules under the hood which components use so we can make changes easier and improve compatibility across the framework. Along with this I want to slowly move over to TypeScript and also SASS.

This may all seem very similar to the original plans however this approach will be retaining the current library and be more of a refresh of tools under the hood. So in the end we'd have no or at the very least very few breaking changes to the end library.

Hopefully this all makes sense however as always feel free to comment and ask questions.

[y0hami]

I'm closing this as the primary focus of why this was opened has changed.

Thanks everyone for contributing and helping us along the way!

[SteveALee]

@hammy2899 Could you provide a link to the latest project vision/goals and roadmap? Why the fork originally?

We are thinking of using for a small company site. Accessibility is key but I found no mention of that either.

I did see your comment above about updating to more current tooling which is good as I rather gulped when I saw gulp :-P These days vitejs is gaining massive traction for good reasons.

[y0hami]

@SteveALee I'm gonna be as honest as possible as I always try to be. As of right now FUI should not be used for new projects in my opinion.

When we first forked SUI the web was still in a period of time where the way to build sites was to include your framework/library via CDN and write JS files etc and include them via script tags. When I first planned v3 I saw a movement in the way the web was being developed and took this opportunity to migrate FUI to a framework based on these changes and to provide a full solution to the problems of developing websites. As everyone should have realised by now the web has changed a lot over the last few years and I can confidently say my plans were correct however we never had the resources available and some tooling was missing which we needed along with some personal life which prevented me from being as involved as I wanted to be. This led us to never getting to build v3 the way we wanted and now we've fell behind in current trends so there is a lot of libraries and frameworks out there which are better suited then FUI.

With all that being said FUI isn't dead like I said above, we (mostly @lubber-de) are still maintaining the library and do wish to execute our v3 plan but with a lot of changes to make the scope smaller but it will be a while until we've caught up with current offerings.

If you want to see a roadmap this was our old one however most of it is still valid but I'd suggest reading through this issue if you haven't already as it will give you insight into what we're going to do in the future too. As for why FUI was created:

Fomantic was created to continue active development of Semantic-UI and has the intent to be merged back into the master repository once active development can restart. For more info please read the following issues Semantic-Org/Semantic-UI#6109 Semantic-Org/Semantic-UI#6413

but as also stated on the readme lots has changed since the fork so the chance of merging back is basically zero.

I hope this info helps you but if you have any other questions feel free to ask!

[SteveALee]

@hammy2899 Thanks for such a quick and helpful answer. Especially as the issue was closed :)

I understand the dynamics and state the project is now in. It happend. And you confirmed my hunches looking around the project trying to figure the status. Lots of fantastic work here, though.

I'll have a think but will probably heed upur advice.

Thanks again.

[dorner]

I'm going to register my contrary opinion here. In fact, there is a recent move back to the CDN approach of doing things, using importmaps: https://github.com/WICG/import-maps . This is the approach being pushed by Ruby on Rails, for example: https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755

I absolutely love using Semantic/Fomantic for non-SPA's with a small amount of JavaScript, which is the majority of what I write. The simplicity of being able to define a couple of classes and a tiny amount of JS to create beautiful, well-featured UI elements is something no other framework really offers. Fomantic has a bunch of elements that Bootstrap doesn't, for instance.

I don't agree that the build process should hamper the development of this framework, nor that it should be abandoned for new projects.

[alexnicolaisen]

I really appreciate what you guys have done from SUI to FUI, and was really hoping for a living product after the great start you had with lots of new functionality and sorting out old errors. After being stuck with a dead SUI for years, it now sounds like we are soon back there again...

I really don't get why the FUI-team looks all around and try to be a "Me too"-product... Why not believing in the way FUI was heading and create something that the users can't get anywhere else? An easy-to-use beautiful UI.... Why should the development die because we are guessing that most of the others move in one direction. Why not create something that your users love and let the rest of the UI-herd battle for their users?

I hope that you again can summon a small team of developers that devote some hours each to take FUI one step further every month. No need for a total makeover or some major changes, but just keep this fork alive 🙏🏻❤️

[jkytomak]

Sad to see this closed.
Hopefully library will still be maintained.
I see recent new commits in develop.
Any plan to making new release? Latest is over year old.
We get many old library versions via fomantic.

[lubber-de]

Yes, we will still maintain FUI :) 2.9.0 is on its way, the nightly build already has everything available from the current develop branch

[bborn]

Just piling on: FUI is pretty great, mostly as-is. No need for huge re-writes or doing what 'everyone else' is doing (if I liked Tailwind I would have switched to Tailwind years ago). Just normal maintenance and reasonable improvements when possible is much appreciated.

[v3ss0n]

Sad to see this closed. Hopefully library will still be maintained. I see recent new commits in develop. Any plan to making new release? Latest is over year old. We get many old library versions via fomantic.

Suddenly it was abruptly back to life it seems. There an october release 2.5

[inviridi]

Thanks for reviving this great framework and the work you put in to make frontend development fun (for me)! I guess, I'll be fine with whatever you come up with... the current state is pretty fantastic already, and I am sure you guys have the best intentions to keep it this way.

[matthew-dean]

From the Roadmap:

Move from LESS to SASS

😢 Can I ask why?

[Jogai]

@matthew-dean probably because the majority is shifting to sass, some stats here: https://www.keycdn.com/blog/sass-vs-less