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.