The future of Fomantic as v3.0

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)

[hammy2899]

Update regarding v3

We are approaching the 1 year mark of the v3 announcement so I wanted to give a public announcement let the community in on what we have been doing over the past year and also to give a more defined list of whats to come. I will also use this post to clear up some confusion which I keep seeing.

To start lets talk about what we (me, @lubber-de, @prudho and @ColinFrick) have been up to this past year.

The first thing we did was look into how we could reuse the current code base as much as we could to speed up the development process however this turned out to be more of a pain so we made the decision to actually rewrite the entire library, JavaScript and CSS from the ground up. This was a huge task however it also brought a lot of benefits. One of these benefits was we could rewrite every component in modern JavaScript allowing us to use new APIs which simplify the code base and improve development time. It also can improve performance in some cases. Another benefit it brings is it allows us to improve the user level API access to components allowing you to do more with components which intern allows us to add new features better and quicker. The rewrite of the CSS is also exciting because we have made the decision to move from LESS to SASS which allows us to use some of the new SASS features which makes theming easy for users and it also allows us to improve the CSS specificity hierarchy.

Of course rewriting the whole framework from the ground up is a huge task and a lot of work needs to be done which brings me on to my first point which I need to clarify. A lot of users have been asking when v3 is going to be released and some people expecting it to be done soon. Please remember we are only a 4 member core team working on v3 and we all have our 9-5s and our general life. We work on FUI in our free time its not our full time job which is why its taking so long. Don’t get me wrong I’m sure we would all love to work on FUI full time but right now that isn’t an option. This is also one of the reasons we aren’t give a specific date for when v3 will be complete. I have said this a few times but once v3 is available to the public in any form alpha, beta or early access we will announce it and if you follow the project you will most likely know about it. If you want an easy way to follow the project for updates follow our Twitter (fomanticui) or join the community Discord server.

Now for some details on what we will be shipping.

We have decided to ship 3 core libraries DOM, React and Vue (these are the libraries we are promising to ship before our production release not our first public release) the reason we have chosen these 3 is because they are all the current most popular frameworks and a good starting point for our first party integration portfolio. Also most users using FUI ask for React and Vue implementations more then any other framework. This does NOT mean these will be the only first party supported integrations. We are building v3 with a agnostic framework layer which makes these implementation libraries possible because it keeps feature and implementation details the same across all integrations. This also helps third party frameworks create their own binding to FUI (If you are building a framework and want to support FUI please reach out to us via contact[at]fomantic-ui.com and we can have a chat and give you support regarding the agnostic framework layer).

The agnostic framework layer is currently one of the main aspects we are working on right now so we can create the best way to build implementation bindings from the agnostic layer to the user library layer. What does this mean? Lets go into more detail on how v3 will work under the hood. This agnostic layer I have mentioned a lot already is the starting point of any JavaScript component in the framework. You can think of the agnostic layer as a template of how components should work, it defines what methods each class should have and what arguments they require and what they should return (it does a little more like manage state etc but I’ll keep it basic for now). This forces all integration libraries to be the same for the user so if you use the React library on project A but use the Vue library on project B the tab.select('first-tab') method will be the same on both because the agnostic layer has specified the tab class needs a select method and the method requires the user to specify the tab ID. This helps with consistency across all integrations making it easy for users to learn new front-end frameworks while using FUI and also helps us as developers keep the same functionality across all our libraries making our life easier with support and development.

We are currently working on the agnostic framework and mainly the binding from it to the user library layer to make the experience best for us the framework developers and you the framework users.

What’s next on our list, well next I want to work on the SASS/theming implementations because as you could guess this is also important for how it works so will need a lot of work to get perfect.

We also need to finalize a build process/system, we have a basic one setup right now but it will need more work as the framework becomes more complete.

The monorepo? You may have saw I mentioned moving to a monorepo and I can confirm v3 is a monorepo which supports the current implementations very well and actually really helps with some problems like the build process. Lots of people are scared that the monorepo will make the framework hard to use or hard to contribute to. I disagree with this for 2 reasons 1st the monorepo will have no impact on normal users because you don’t need to use the repo anyway and 2nd contributions are actually easier because the monorepo structure is easy to navigate and it makes it easy to find where you need to be for your changes. This will be apparent once you get to see the repository.

New components? Yes v3 will have new components however we haven’t started to develop any and we won’t for quite some time because we need to work out how the whole thing will work first.

General code and API changes will be done within the rewrite so moving icons to data-icon and removing/adding new component APIs will happen naturally in the process. This means we don’t have a definite list of API changes.

Now for the biggest and possibly the most controversial changes to our plans.

First we plan to support all latest browsers which means dropping IE support. The browsers we will officially support are

• Chrome (including Chromium)
• Firefox
• Safari (Mac/iOS only not Windows)
• Microsoft Edge (Most likely Chromium version will be generally used when v3 is released)

Why are we dropping IE support? We are making v3 a modern framework and we can’t live up to that standard if we support IE. IE is old and doesn’t support modern JavaScript or features which we want to use and adds a lot of complexity to our development if we support it so we have decided to drop its support. I know quite a few people will be annoyed by this change because they use FUI for commercial systems and their users only have IE but the only way the web can move away from legacy systems is by actually stopping the support for them (I will also be affect by this change so its not a case of us not caring about our users). This doesn’t mean the framework won’t work on IE because most likely a lot of CSS and JavaScript will still work this change only means we won’t support IE meaning we won’t patch any bugs which are only relevant for IE.

The second big changes is v3 will not be backwards compatible. Now a lot of people will be angry by this change and there will be a few people asking why I have to mention this because its a major version jump so obviously it has compatibility issues however we originally said we would provide something like a polyfill so users could upgrade without needing to change their codebase however this is becoming more unlikely as we continue the development. This is NOT us saying we won’t do this but we will might not ship v3 with this polyfill because from a small review we had it would actually require a lot of work to do this and the polyfill actually won’t be perfect because of some of the changes we want to make. So some features might not work because they have been removed/changed resulting in unexpected behavior. This is actually a complex and delicate subject so I understand there will be some users angry by this change.

So some of you may be wondering where can you see our work on v3, well actually you can’t… yet. We are currently working in a private repository intentionally mainly because there we can work without any interactions so it allows us to move development swiftly and make decisions like some mentioned here. I understand that some people might be still wondering why we are doing it in private when I made a promise from day one that this was a community project and your right I have made issues regarding changes like our possible brand change however I think working in private for now benefits us and make it a lot easier for us to move rapidly that being said once we are at a stable point in development I will make it public for everyone to see and fiddle with. Also we have some special changes we want to make which aren’t on this list and will be a big surprise and we don’t want to leak them 👀 so stay tuned.

---

I understand this is a huge wall of text but like I mentioned above this is a community project so I wanted to let you all know the current progress and what we have been up to because from your point of view it will probably look like we’re doing nothing about v3 which is wrong 😉

There’s a lot of controversial and exciting changes in this post but hopefully you accept and agree with our decision on the changes however if you don’t feel free to discuss below and I will answer any questions you have ❤️

---

TLDR:
If you don't want to know the in's and out's or don't have the time to read this wall of text read the following.

We have been working on v3 since the announcement last year even if it looks like we haven’t, this is because we have been doing the work in private repositories. We have made a few changes to our core plans for v3. First we have decided to create a agnostic framework layer which we will use to keep all the integration libraries APIs the same so it is consistent for users. Second we are dropping IE support and will now only support modern browsers. We are doing this because v3 is a modern framework and supporting IE holds us back on that goal. Third change is large, we won’t be providing the backwards comparability polyfill as mentioned in the past. At least we won’t be at the start however if we can and we get the time we will do our best to do this but we aren’t promising. Fourth change we are moving to SASS instead of LESS so we can provide a better theming experience.

[lubber-de]

The following is my personal view/opinion on the current situation:

A v3 (meant as a complete rewrite with all the ideas mentioned in this thread) is not going to happen anytime soon. First drafts were started which are far from being releasable (not even as an early alpha)

• Every module has to be rewritten (while we still maintain v2)
• Too less maintainers (with enough time) (volunteers welcome!)
• v2 gets issues which are related to unmaintained dependencies

Even the suggested fast.design approach would need a lot of time, is a whole rewrite and needs additional maintainers. (volunteers welcome!)

As you probably have already recognized, we are currently focussing on improving the v2 api as much as possible, so people should not be worried about getting huge breaking changes.

For some time now already, i am investigating into writing some compatibilty layers/function wrappers to make the existing codebase compatible to other frameworks (or even smaller jquery alternatives like cashdom/jquery slim,…) as this was the most desired concern to get rid of jquery and also being able to use other frameworks like react/angular/vue/etc.

Look at all the existing ports which try to rewrite the original SUI for those frameworks. None of them are feature complete to SUI. (look at the sui-react and others…not even those projects support all the features of the original SUI yet (think of transitions…).

Then people are complaining about node 15, yarn, pnpm and so on (for v2!) 🙄 Well, it’s a community fork: Please try to help and fix things yourself and provide a PR afterwards. If you are able to code JS to use fomantic, you most probably are also able to fix some things yourself and donate your work to the community. 😉

We currently also suffer from not responding maintainers of used dependencies which seem to have lost interested in their projects, so we have to think about either forking those (sometimes ridiculous small functions…) ourselves (which i dont really want) or rewriting/including the dependency code directly into the core (which is not the idea of reusing software, but the downside is…well…the dependency…)

What will most probably happen in a next bigger/minor upgrade (i would target 2.10) will be a decoupling from common functions from each js module into a central module (think of the “debug” features) while still keeping the codebase / api mostly backward compatible to also reduce the codebase.

My personal approach is to keep the original idea of SUI: Providing a CSS Framework, but people are still on their own to build the html (instead of providing webcomponents even for non JS elements like input/button/header/list/etc in sui react). This way you are most flexible in your design/usage (and this is the v2 way ever since)

I think doing such improvements step by step will be more successfull than doing everything from scratch (if only a few people are willing to help…). Maybe at some day we can name it “v3” then.

Again, this is my personal view/opinion from the current perspective and not necessarily the future of the framework.

It’s a community fork. It’s YOUR fork. Everybody is welcome to provide PRs and make it better and build the future of FUI/SUI!

Thanks for reading 🙂