Fomantic-ui: The future of Fomantic as v3.0

[hammy2899]

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 https://github.com/fomantic/Fomantic-UI/pull/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. :thinking:
We have to discuss this further. There are always pros and cons. That`s why we will hear your voice :slightly_smiling_face:

[hammy2899]

@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)

[hammy2899]

@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 https://github.com/Semantic-Org/Semantic-UI/issues/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?

[hammy2899]

@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 🙂

[hammy2899]

@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

[hammy2899]

This is my opinion/perspective on funding and I think a lot of people will agree.

Right now FUI is very young and doesn't cost anything to run, the only thing which has cost money is the domains which I have bought and am willing to pay for every year. As mentioned above we do want to start advertising once v3 is released which would of course cost money every month and once we develop the theme builder and "store" websites the hosting costs for those servers. Now this doesn't include to cost of developers time but isn't this the point of open source 🤔 we work on FUI because we want to not because its our job to. That being said I think having bounties on issues would of course draw more people into contributing but IMHO that could make people make PR's to fix issues to get the money and their fixes could be cheap and hacky.

I can say for myself and the FUI team since we started FUI we have been rejecting money from people wanting to donate and even removing the ads from the website because its truly not necessary right now.

With all this said in the future we will of course need some money for hosting the sites as mentioned above and I think the best way to do that will be in the most open way possible because I think more people will be willing to donate if they can see what we spend it on and where their money is going to go. Again I don't think we will set anything up until we need it which will be a while.

[hammy2899]

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

[aardbol]

@hammy2899 Wouldn't a better approach be to invest time (or money) into creating more real life examples of how FUI is used instead of just advertising on external websites? Why would someone who's for example used to using Bootstrap, and is very happy with it, be convinced to click an advertisement about FUI and invest time into trying to use it? Would tech savvy people even see the advertisements, because most of them know how to block them?

I'd be willing to contribute on that part, as well as documentation.

While I support your approach to do it "the open source way", I don't think you should rule out commercial opportunities that could open up in the future. Open source doesn't mean nobody gets paid to work on it full time. Donations are good, but I don't know if it's sufficient to have a stable cash flow to keep things running. If such an opportunity would open up, it can only mean good things for FUI, of course as long as you keep the license the same though.

[pfcodes]

Webpack for the build process?

[domenkozar]

I'd highly recommend https://parceljs.org as it has way better defaults and pratices convention over configuration.

[lkraav]

Web Components space https://developer.mozilla.org/en-US/docs/Web/Web_Components definitely needs more UI framework competition. Polymer, Ionic v4, Vaadin is probably not enough.

[hammy2899]

@phlfvry @domenkozar I have used both Webpack and parcel and I think they are both great but might not be what we are looking for since they are bundlers and we need something to build the JS/LESS.

@lkraav Web Components looks good but I don't think we will implement it with FUI since browser support isn't 100% there yet.

[levithomason]

@hammy2899 Hello 👋 I am the author of Semantic UI React (SUIR). SUIR started as a separate project, like Fomantic, and was a complete rewrite from scratch. After becoming useful and gaining attention, it became part of the Semantic Org ecosystem. That was about 4 years ago. Since creating SUIR it has now been used at great companies like Netflix and Amazon, and a bit at Microsoft. We now get about 150,000 downloads every week.

During the last few years, I've also had a few video calls and in-person meetings with Jack (original author) about the full story behind Semantic and its hope for the future. My experience rewriting Semantic and the vision I've absorbed from Jack has drastically reshaped my perspective and goals compared to 4 years ago. Your current plan in this issue is similar to what I had thought in the beginning. If I did it all over, I would have done it differently.

I am now in a position to rewrite Semantic again. In fact, we're quite far along. What we're working on now has a garnered some attention from companies like TopTal, Uber, and Microsoft. There are also a lot of similarities to what you've noted in this issue. If you are going to embark on this effort, I'd love to catch a video call with you and see if we could collaborate. It could end up saving us both tremendous amounts of time and producing a much larger impact.

Let me know if you're interested in a video chat. Regardless, best of luck with the project.

[lkraav]

Web Components looks good but I don't think we will implement it with FUI since browser support isn't 100% there yet.

100% is probably not the number to aim for. Polyfilled support has already become far enough to work with today (esp on new projects that will take some additional work time to even launch).

But WC technology is certainly a big philosophical change (very thing I'm going through right now on my own business platform). In light of @levithomason's message above, I'm quite interested in hearing his .02 on WC, as well.

[douglasg14b]

@levithomason If this gets to a stage where you and your team can collaborate with Fomantic on a rewrite, I can't help but wonder if this could be done in a framework agnostic way with web components/custom elements? This should also enable Angular, Vue, and others to integrate Fomantic right out of the box without trying to kludge it in or rewrite it. I also imagine benefits like scoped CSS would be a massive boon for the framework as well.

What are your opinions on this?

One way or another though, I would see it as a huge success for you to provide your support/development to the project. Especially if it helps it integrate into the already mature ecosystem that Semantic spinoffs/adaptations have created.

@lkraav I agree that 100% isn't something to aim for, also take into consideration the time that such a rewrite might take. If it takes 18 months, what will the WC API and it's support look like by then?

[ansarizafar]

I would recommend using upcoming SvelteJS version 3 https://v3.svelte.technology for creating small and reactive components.

[gaurav-]

I second @douglasg14b. Ideally, the efforts should be maximized on a core framework-agnostic implementation. Stardust-ui/react could then be a reference implementation for React.

The work done so far by @levithomason could perhaps be repurposed for the rewrite of the core, and some iterations would also be saved on getting the core framework-agnostic API right. And if there could be at least one more reference implementation (maybe web components, or even angular?) then that would be an even better test of the framework-agnostic-ness.

This is an exciting proposition!

[batata004]

I really dont understand the reason to spend so much time removing jquery dependency. Most of the modern websites nowadays rely on jquery. Devs already imported jquery into their projects/websites. Removing jquery dependency means that on websites that already need the jquery usage, will have to load lots of uneeded code from Fomantic UI only to manipulate the DOM.

Respectfully, I think jquery dependency is a great thing. Jquery code (mainly the 3.x version) is already very optimized, fast and I doubt fomantic ui will manage to created faster selectors/routines. On the thousands of websites the company I work for manages, I think jquery is present at least on 90-95%. The ones which dont use JQUERY probably wouldnt need FOMANTIC at all cause they are just very simple projects.

Removing jquery will demand LOTS of testing. LOTS. Will demand many bug fixes. And if you remove jquery dependency you will require devs to change all their codes from small thinks like $("#xxx").modal() to more complex things.

Fomantic UI has to keep backward compatibility. If Fomantic UI is looking for a complete different path as SEMANTIC UI and be not fully compatible anymore, I will sure be going back to SEMANTIC UI. Semantic UI is lazy on the updates and many other disadvantages but I will sure stick to semantic ui if fomantic ui gets no backward compatibility - it would be a great pain in the * to change all websites we manage here just because "fomantic ui decided to remove jquery dependecy and increase 20% or even more of its own code with code that is already present in jquery library - making loading fomantic ui in parallel with jquery slower and heavier**".

[ColinFrick]

@batata004 You are correct that jQuery is used on about 98% of all websites, but this is mostly version 1.x (85.8%). jQuery with version 3.x is used on only 6.4% of all websites (https://w3techs.com/technologies/details/js-jquery/all/all).

Most of the usages can be replaced directly with native browser function (http://youmightnotneedjquery.com/):
$('.my #awesome selector'); => document.querySelectorAll('.my #awesome selector');

There are plans to build jQuery 4 with es6 modules, which seems interesting, but to far off currently: https://github.com/jquery/jquery/wiki/Roadmap

For me the target is a framework agnostic vanilla implementation with different wrapper (as mentioned before even a backward compatible jQuery wrapper).

[labby]

@batata004
I agree to 100%, and I also think that jquery will be upgraded on sites to 3.x. ( i remember discussion about IE6 lightyears ago :-) )
I suppose all the needed manpower could better be spent in developing new (more, other) features and bugfixing.
Only my 2 cents...

[batata004]

@labby totally agree with you "_all the needed manpower could better be spent in developing new (more, other) features and bugfixing_".

Makes no sense to me "reinventing the wheel". jQuery is out there, everybody* uses it and with nowadays modern processor/smartphones/browsers... makes no sense embedding all jQuery goodies inside a platform/framework since one can simply load jquery inside a project and use it.

I know some (not many) of jQuery selectors are already implemented natively by modern browsers. BUT things like addBack(), last(), contents()... are very handfull and jquery already provides that - even the most browsers dont (nodes[nodes.length- 1] does not count as last()). I also think things like "filter(), find(), children(), parent(), map(), not()" are also not easily accessible using native modern browsers solution.

Anyway, despite the decision devs of fomantic ui take regarding jquery, I AM PRETTY SURE the new path it's taking is gonna be amazing! But removing jquery and breaking backward compatibility will leave me out of this path and I will have to go back to semantic ui - with lots of sadness.

[labby]

breaking backward compatibility will leave me out of this path and I will have to go back to semantic ui - with lots of sadness.

The same with me...
We spent lots of time developing a cms backend-theme with semantic-ui and twig template engine.

[lubber-de]

@labby

I suppose all the needed manpower could better be spent in developing new (more, other) features and bugfixing.

That's what we are also still doing in parallel :slightly_smiling_face: Have you seen those many SUI bugfixes we did in the past 2 weeks just for the upcoming 2.7.2? New features and components are also in preparation for 2.x.x.

@batata004
I agree with what @ColinFrick said: Being prepared for whatever other framework you are working with and might appear on the JS-Framework-Sky of the future ... or vanilla JS.
Maybe $('.ui.dropdown').dropdown() is still working in 3.0, but does other things under the hood with some kind of "framework-adapter" as wrapper doing the trick.

With support from @levithomason there might be chances of miracles :wink:

[hammy2899]

@lkraav "100%" was probably the wrong term to use here. What I meant was browser support isn't good enough for the browsers we want to support and the time it would add to the development would be too large. Maybe we can create an implementation further down the line.

@douglasg14b @gaurav- I have been thinking of this for a while now and I do agree that making one centralized JavaScript library which can be used to create implementations for such things like React, Vue, Angular etc would be a good approach and is kind of what we are going for with v3. I will discuss this further with @levithomason.

@batata004 @labby Removal of jQuery is a big topic and has been mentioned a lot already. We have said we are looking into removing it but I want to emphasize this is not 100% happening as of writing this.

We (FUI team) have discussed a few approaches to this problem already but we have not made a decision as of yet.

I just want to make a quick point, if we keep jQuery that does mean that websites which don't currently have it and want to use FUI they will then need to include jQuery. Where as if we remove it websites which don't have jQuery don't need to add any dependency and websites which do have jQuery also don't need to do anything. IMHO I don't really see why there is an argument on whether to remove or keep it but I lean more towards removing since it is getting rid of a dependency which is mostly used for functions which are native to browsers now.

Also removing jQuery can allow us to make implementations for React, Vue, Angular etc a lot easier.

Please read this conversation where we go over the topic in good detail https://github.com/fomantic/Fomantic-UI/issues/319#issuecomment-449402969

[hammy2899]

@levithomason Hi, great to see you found FUI 😃 I would love to have a call with you and I am sure a few members from the FUI team would also join if also invited 😜

Let me know some times and dates and we can work something out! (all the FUI team members are EU based)

[levithomason]

but wonder if this could be done in a framework agnostic way with web components/custom elements?

Yep, this is exactly what we're doing. It is quite obvious once you rewrite a component over and over that there needs to be a single framework-agnostic solution.

We're creating vanilla JS solutions to state, styling, and accessibility. Then, we're tying this into React. However, you could tie them into any framework. A single update to the accessibility abstraction will apply all changes to all frameworks. Same for state management and styles.

I've also tested some web component approaches. I'm not convinced this is ready as the primary solution just yet. But, it also needs more testing.

Again, there are several years and many minds worth of ideas and work behind what we're doing right now. It is a bit tough to summarize in this forum.

@hammy2899 I'm available Tue/Wed and Fri at 5pm your time (Newcastle, UK). Shoot me an invite for a day that works for you, [email protected].

[labby]

@lubber-de
this was not meant to blame you nor the team but to see a chance :-)
And yes, for sure I noticed development and we are testing FUI 2.7.2 right now for next release.

Whatever you will decide in this case, it's fine with me as I said above.
But again, for me there is no need to remove jQuery and getting rid of 2 (or 1) lines (for integration) cannot be an argument to do this.
But I respect all your arguments and decisions, please also respect mine.

[lubber-de]

@labby

please also respect mine.

I definately do! :slightly_smiling_face: Sorry, if my comment got mislead! :handshake: We want to hear your opinion, that's why this thread was created

And i love, you guys are already testing the next version! :+1:

getting rid of 2 (or 1) lines cannot be an argument to do this.

Of course! :laughing:

[labby]

And i love, you guys are already testing the next version! +1

Sorry for this, of course 2.7.1 was meant.
If we were testing 2.7.2 we surely were part of FUI-team :-)

[batata004]

Ok, clearly the future will be without jquery. Later on the road you're gonna see how much time you spent just to remove jquery dependecy - time which could certainly be spent elsewhere.

The company I work for developed a very complex framework based on Semantic UI and many other libraries. This framework contains around 12k websites running its custom code, content management system, custom backup routine... When we moved from Semantic UI to Fomantic UI it was as simple as changing a "switch" cause we just had to change the CDN line to point to Fomantic UI instead of Semantic UI. All website had already jquery enabled.

BUT, if from now on, code like $("#xxx").modal("show") gets changed to FomanticUI.modal("#xxx","show") or even FomanticUI("#xxx").modal("show") it's gonna require huge changes and troubleshooting on many websites that already used fomantic ui so far.

You would invest much better your valuable time bringing addons/plugins natively like calendar which is a huge miss for Semantic/Fomantic cause anyone that seriously want to use a calender UI has to use external plugins.

Said that, I clearly lost this battle. I just ask you that as soon as you plan to break backward compatibility you be clear about it so I can move back to Semantic UI - which is lazy on updates but after some months always updates its code.

Just to be clear on my point cause I may have been misunderstood: nowadays 95% of websites we develop here already need jquery. I will give you JUST and example, with total random numbers cause it depends on jquery version, gziped, minified...

Nowadays, on my "example website" when I embed jquery I need 100KB and when I embed fomantic ui I need 300KB. Total: 400KB.

If you remove jquery dependency I will have to embed jquery anyway (cause I already need jquery) so I will have to load 100KB. Then I will also have to fomantic ui which will not be 300KB in size, it will surelly be at least 10% larger cause you will have to deal on your own with your selectors, chaining... Just to do exactly the same thing jquery already does. Memory consumed in the browser will be greater, time to page load will be greater... no gain, just pain.

[ColinFrick]

@batata004 this has been addresses many times in this discussion. Who says that FUI is going to increase in size?

FYI calendar is already implemented in Fomantic UI: https://fomantic-ui.com/modules/calendar.html

[batata004]

@ColinFrick FUI will not be bigger in size when it removed jquery dependency? So how will you do all the "selector" stuff without adding new code? "queryselectorall" will not do all the heavy lift on its own.

PS: thanks for pointing the calendar, I was not aware FUI had it!!! GREAT!

[etshy]

@batata004 you can still stick to v2.x.x of fomantic to have jQuery, no ?

And when v3.x.x will be released + a jQuery wrapper, you'll get all you want.

I can't understand your worries here, when semantic ui is clearly too slow to be interesting to use at the moment.

[batata004]

@etshy so let's wait to find out. I agree with your last statement. However, I better stick with SUI (despite slow updates) to avoid changes/troubleshooting on thousand of websites when FUI decide breaking backwards compatibility.

[hammy2899]

@batata004 I think you have misunderstood something while reading. In this comment and the following replies we mention about adding a "pollyfill"/adapter from v2 to v3, this will mean all your websites will work exactly as expected with no code change even if we remove jQuery.

Your point about FUI increasing in size. The library won't increase if we remove jQuery since we will be removing jQuery it will be reducing the size because we will be using native functions.

[Atulin]

Also, the current code is not exactly up to modern standards in all places. Removal of jQ would also be a good opportunity to go over the entirety of the code, finding unoptimized pieces and optimizing them.

Far as I can tell, the removal of jQ will most probably result in decreased size and increased performance.

[batata004]

@hammy2899 great news!

@Atulin @hammy2899 time will tell if the "jquery less" version will be smaller. Respectfully disagree, you cant make a code smaller adding news features (like removing jquery). Somehow you're gonna have to code your "selector engine".

I dont want to keep this jquery discussion further, I dont want to bother you guys here with this jquery thing. It's a bold move and clearly it's gonna happen and, despite disagreeing, I know for sure you are doing this for the better :) Keep on good job!

Just one question, unrelated to this thread (sorry for posting here): I didnt know FUI used calendar and I checked the component and it works amazingly well! You did a master job with it, simple and effective. I was not aware of it and, after reading the documentation of FUI, I didnt find any component/code related to "masks". For example: when user types a phone number a mask would automatically add ()- chars as needed. I just want to make sure I am not missing anything! Could you confirm that "masks" are not implemented with fomantic? I will remove this last phrase if not answered in the next hours to avoid breaking context of this discussion.

[lubber-de]

@batata004 masks for Form inputs are not yet implemented. But it's a good idea I can think of an enhancement of the already available Form validation behavior to work instantly on input fields instead of validate only on Form submission ... Would you like to create a feature request issue? 😉 So we can continue talking about that in a different thread.

[batata004]

@lubber-de sure! Thanks a lot! I will do that right now and provide you a link of a good jquery mask library that we use here for years and it works great!

[levithomason]

It would be really great to discuss collaboration and sharing before this project progresses too far ahead. The primary focus I have is in sharing state, styles, and accessibility. These things are common between all implementations.

Consider that there is a SUI jQuery dropdown of 3,955 lines, a SUI React Dropdown of 1,425 lines, and now a Fomantic Dropdown of 4,113 lines. This component has the highest rate of bug reports and feature requests. The sad part is, we share only CSS between the implementations. What a shame that every bug fix and feature needs to be reimplemented over and over again.

Every one of these Dropdowns is a finite state machine. They all need to open on spacebar. They all need the same aria-* attributes on the items within. The list goes on for a very long time here and for every component.

Wouldn't it be great if UI framework components had the same consistency and expectations that HTML elements do, for developers and end users? Web apps are only possible due to the consistency of HTML/CSS/JS across browsers. Imagine what we could do if we had an open standard for more advanced common web app components, like calendars and dropdowns.

We could save untold manhours by creating vanilla JS solutions for state management, styles, and accessibility and sharing those in all three implementations. As I've eluded to above, I'm actually leading teams full-time at Microsoft on this effort right now. We have a dedicated accessibility team, accessibility contractor, designers, UX engineers, and software engineers working full-time across two continents.

Anywho, I'll leave this conversation at this for now. We'll publish much of this information and many packages through 2019 on this effort. It would be so superb to have a motivated and capable group of Semantic UI folks like yourselves join us.

[khornberg]

@levithomason That is a great goal. I am curious what you will publish. My understanding has been that Web Components were supposed to do that.

Where will you publish

this information and many packages through 2019 on this effort

[douglasg14b]

@batata004

My $0.02 on JQuery. Before I begin I'll say that I still use JQuery on many projects that don't use a framework like Vue, React, or Angular. It provides plenty of functionality that vanilla JS still doesn't.

It's not used everywhere (contrary to claims, most of it's usage are VERY old versions), has been effectively replaced by many vanilla and framework alternatives. It's clunky, messy, and will drag down the framework in the future where JQuery will no longer exist in mainstream applications. There is no reason to have a death-grip on the past that is JQuery. Your arguments that the time can be better spent else-wear is a false economy, as it will cost much more time in the future to remove JQuery Which WILL happen eventually. And cost an indescribable amount of dev hours for users of the frameworks who are held back by the JQuery dependence, and the bugs/issues/slow development inherent to sticking with it's patterns. When we could be making an agnostic framework that works out of the box for SPA frameworks. You are potentially hamstringing the future of the project by forcefully keeping a dependency that has been fading from modern use...

Other UI frameworks have already made this leap, and are ploughing forward and leaving Semantic in the dirt to wallow around as part of the "old guard". Similar to how NLog or Log4Net are nearly considered legacy in the .Net ecosystem for their inability to adopt new ideas and paradigms. Lets not become a legacy framework.

---

We have something great with @levithomason who appears to be using vanilla JS/Web Components to build out SemanticUI in a more framework agnostic way. Which is EXACTLY what anyone could wish for from a modern UI library/framework. It would be silly to throw away the opportunity to work with what I could only consider a sponsor (through time, not money) just to hang out in a comfort zone. The web will move forward, with or without Semantic/Fomantic, and all of us are sitting on an opportunity to push Semantic/Fomantic ahead of the pack. Lets not squander it.

[douglasg14b]

On second thought, I think JQuery-related discussion should be in it's own thread/issue to prevent it muddling up more important conversations about the future of SUI/FUI. Not that the JQuery conversation isn't important, but it's divisive, which can be very bad for a discussion meant to be future-facing. Since it shifts the focus into an argument over one item, instead of a discussion about the framework as a whole...

I fell into that trap with my above comment. and contributed to the off-topic mess.

[hammy2899]

@douglasg14b I agree, this thread is starting to get slightly off topic...

[douglasg14b]

@hammy2899 If so, is there a way to move comments to another issue? Failing that, copy/pasting them as quotes would do if a line can be drawn pushing that conversation over there.

[hammy2899]

@douglasg14b I will sort something out 😉

[batata004]

@douglasg14b I agree with most what you said but I was never trying to predict the future. You said that in the future jquery will be "legacy". Sure. As will "Fomantic/Semantic". As time passes by, browsers are implementing lots of standards and helping devs to spend less and less time with that "semantic stuff". I am pretty sure, a few years ahead, it will be much easier to users customize their websites/buttons without relying - or having to choose - a framework. You certainly will be able to use frameworks but they will add more than an overhead than a significant leap. Today, FUI/SUI helps A LOT when building apps/websites. In the years to come, I dont think it will be that much* important. I just want to say that, when jquery is gonna be considered "legacy" I am pretty sure most of what FUI/SUI provide today, will so too. But I understand the reasons why devs usually want to create "indepedent framework" ("jqueryless", for example) and most of the time I dont agree. But I've been wrong much more times on my life than right, so yeap, dont mind my opinion.

I also agree with @@douglasg14b that this jquery discussion shouldnt be part of this thread and I promise I will stop posting about it.

[levithomason]

That is a great goal. I am curious what you will publish. My understanding has been that Web Components were supposed to do that.

@khornberg Web Components offer an API for creating custom HTML elements. They are often used in tandem with the Shadow DOM to isolate HTML and CSS to your component and solve the bleed problem. That is where it stops.

First, we are defining:

• Component names
• Component slots (anatomy)

This will give the UI community a common language for talking about components, but more importantly, for sharing code. We can't share abstractions if we don't use the same terminology.

Second, armed with consistent naming and reliable anatomies, we are creating vanilla JS abstractions for:

• State
  Vanilla JS state managers that produce a JSON serializable state shape. Each stateful component has a dedicated state manager. The JSON state description is named and structured according to the component names and anatomies above.
• Style
  Vanilla JS functions which return style objects based on component state and a theme. The functions can be used to generate traditional CSS stylesheets or used directly in CSS-in-JS libraries. Style objects are named and structured according to the component names and anatomies defined above.
• Accessibility
  Vanilla JS functions that return JSON serializable objects defining accessibility attributes and key bindings. The objects are named and structured according to the component names and anatomies defined above.

As you can see, once we agree to component names and supported structures for common UI, we can use this specification to create and share abstractions. Imagine if I were to give you JSON objects describing the state, style, and accessibility of a certain Dropdown and asked you to apply it to a component in your favorite framework. This is what we're after. We see UI frameworks as different implementations of the same UI information.

---

Looks like we have a confirmed call this Friday 🎉 Really looking forward it!

[gaurav-]

This sounds like Semantic-UI version of what Ionic4 is doing. Something like StencilJS might be useful. Just a note for the decision makers.

[jouni]

First, we are defining:

• Component names
• Component slots (anatomy)

This will give the UI community a common language for talking about components, but more importantly, for sharing code. We can't share abstractions if we don't use the same terminology.

@levithomason, that sounds super interesting! Is there any way to be involved, or at least follow the process/progress?

[levithomason]

@jouni Our work isn't ready to show yet, however, we are organizing under the https://github.com/stardust-ui organization.

It is not clear from looking at those projects just exactly what we're actually doing. We've been focused on proving out some core patterns and practices for a while. It is looking good, so I'll take time this year to clean things up and make it more presentable and understandable to the public.

[murbanowicz]

I think that one of key points for 3.0 should be making theming easy. One of the worst things about SUI/FUI is customisation. It is really painful to even change the colors pallets at the moment.
It would be great to make it possible to just import FUI less and then perform any variables changes etc which is impossible at the moment...

[lubber-de]

@murbanowicz You may look at https://github.com/fomantic/Fomantic-UI/issues/402#issuecomment-454913211 where it's shortly described how easy you can define the color palette using the names and colors you want at a central place now as of Fomantic-UI 2.7.0
Of course we will also focus to improve this even more in 3.0

[murbanowicz]

@lubber-de I am more looking for being able to easily use LESS file to customize any variables I want etc... I am struggling with that for long hours now and can't get it working (posted an issue #411)

[douglasg14b]

To keep the topic flowing, has there been word on what @hammy2899 and @levithomason might be planning out in regard to collaboration?

[hammy2899]

@douglasg14b Me and the FUI team had a call with @levithomason and he showed us what his team is currently working on and what their goal is in regards to their project. This tied to us because it's basically a rewrite if SUI but in more of an agnostic way which allows us to use that code which would save us a lot of time. We also discussed some other ways we could collaborate like theming, specs and a definition/dictionary repo (sounds weird but it makes sense when you know the full context 😂) and some other things.

We are currently waiting for a prototype so we can mess around and see if it will benefit us and if it will actually work in our project. This is why the v3 talk has slowed down for us a little since we don't want to rush ahead and then find all the work we did was for nothing.

[douglasg14b]

@hammy2899 Thanks for the information! I'm very interested in where this heads as I'd like to contribute to an agnostic rewrite if it happens. Mainly because I do some work In Vue these days, and would love to see a version of Semantic that doens't have the be kludged into components (which has unfortunately caused a couple projects to use other UI libraries :disappointed: ).

The more information the better.

[levithomason]

Confirming what @hammy2899 has stated. We currently have framework agnostic accessibility abstractions that are ready to use in other frameworks. We also have a great start on a framework agnostic styling mechanism. I just completed the first prototype for generating SCSS from our styles and it is going well. I will continue working on this so we can share and collaborate on the abstractions.

In addition to the engineering, we are producing specifications for components. Think of a shared Design System where the language and anatomies are common between frameworks. This is essential so that we can share engineering abstractions on top of the common language and component structures.

...Thanks for the patience, more coming soon.

[Clindbergh]

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.

The "entry point" of this repo, the README.md still states the intent of merging this repo. This note should be removed or at least a link to this issue should be added. It would become clearer that this project is more than a temporary measure, but an active, long-term and new project, whose only tie to Semantic-UI is the original code base and thus be helpful in establishing trust.

I second the point made by

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.

and

How does Fomantic grow it's community and user base under the shadow/growing stigma of Semantic UI?
https://github.com/fomantic/Fomantic-UI/issues/319#issuecomment-449877919

As a user and advocate of Semantic-UI I have found it increasingly disturbing that development seemed stale. I'm glad I found out about Fomantic (and stardust-ui, very interesting!) today and seeing it is actively maintained!

[hammy2899]

@Clindbergh I agree that can be a bit misleading, we are planning to release 2.7.2 this week so I will update the README then.

[mikejf-pr]

Is the intention to maintain backwards compatibility in FUI 3 with SemanticUI components? I'm wondering with regards to the ng2-semantic-ui componentry: if the CSS is compatible, the ng2 components should continue working with FUI3, but if not we'll have to stay with SUI.

[hammy2899]

@mikejf-pr In most cases yes the CSS will remain backwards compatible with just a few changes here and there. These changes may be slight adjustments to improve theming and inheritance (this is discussed more here https://github.com/fomantic/Fomantic-UI/issues/441) and the implementation of a few things like icons will be changed to use attributes like data-icon="user" but in most cases it will remain the same and will require no changes.

[mikejf-pr]

Hang on, are you implying that the old method of using icons via class will no longer work?

If that's the kind of thing you're proposing, I certainly wouldn't call that 'backwards-compatible'. The changes might be easy, but they'd be extensive to the point of affecting everything you've done, and massively breaking, especially with regards to sites that use external integration projects.

I'd imagined that generation and less would be rewritten and granted increased customisation but generated css (not JS) output would remain compatible but extended to new features and components. Sounds like this is much more drastic.

Ultimately, for future things our company would have to follow the choice made by ng2-semantic-ui as to whether they'd support SUI or FUI, as it sounds like they wouldn't be able to do what I'd initially imagined and maintained a core integration set that worked across both sets of css. I certainly don't think there's enough maintainers to fork that project with any reasonable outcome.

[lubber-de]

Regarding the icons we could think about implementing a switch in the config to create the icon classes the old way. But keep in mind, the reason for the new syntax is there are many issues with icon names interfering with usual fomantic classNames, so we thought about an easy way to separate them

[batata004]

I think semantic ui should not use icons on it own, except only the main icons like the X (close button that closes modals)... Icons are too heavy, too expensive to load and so on. Everytime you add more icons, fomantic gets even slower.

What I suggest? If you want to keep a ton of icons embbeded with fomantic code you could go in 2 directions:

1) let users choose only the icons he wants to use in the semantic.json file so when the user executes the gulp build he will only have a small set of icons on his final semantic.min.css file

2) let users choose freely ther icons from FONTELLO - which is amazing. You select the icons you want, you export and you can embed on any project. Super easy. This is actually what I am doing BUT this prevents me from using CDN to load FOMANTIC. In some websites I could easily load Fomantic from CDN but it comes with a huge load of icons that make everything slow. So I have to generate my own semantic.min.css/js files and load it from my server.

Keeping the way icons work in Semntic UI is making this library too "bulky". There is no point making the end user waiting to load 500 icons if on the website the user will just see 3 or 4 icons...

Also, every major framework that uses icons usually make it appear inside <i /> elements using the class attribute to be used to referene which icon the dev wants to show. Using data-icon="user" is not backwards compatible at all and is not even what most libraries do so if could confuse most new users.

[hammy2899]

@mikejf-pr

I certainly wouldn't call that 'backwards-compatible'.
This is why I said in most cases. When I mentioned component changes the biggest change will probably be the icons and as for the icons change I'm sure we could include something inside the v2 polyfill. I also think your way overthinking the changes which we will be doing to the components. We might change a few styles to fix issue but we won't be changing class names and the structure of components and for the theming changes it will only be adding 2-3 classes to your body tag (if we go through with that change).

@mikejf-pr @batata004

Also, every major framework that uses icons usually make it appear inside <i /> elements using the class attribute to be used to referene which icon the dev wants to show. Using data-icon="user" is not backwards compatible at all and is not even what most libraries do so if could confuse most new users.

As @lubber-de mentioned there are lots of bugs associated with the icons because they cause conflicts with their names and the easiest and best way to fix this is to move them into an attribute. Moving the icon names to the attribute also allows us to have better icon names since we can be mores specific in the CSS with names which include spaces etc. That being said yes its different compared to other frameworks but they don't have the problem of the icon names having spaces. SUI/FUI has names like class="american sign language interpreting icon" where as other frameworks could just do class="amer-sign-lang-icon" which is a lot easier to style in CSS without conflicts. An easy example of a conflict could be this class="big text width icon" which is a valid icon but could conflict with the text component, remember there are icons which have words like align, left, right, horizontal, vertical etc. you can probably see how these conflicts can happen.

[batata004]

@hammy2899 nice example you gave :) But then what is wrong with class="amer-sign-lang-icon"? Why do you want to use space instead of -? Also, to avoid conflicts with other libraries, Fomantic could use a prefix on all of its icon something like fui-amer-sign-lang-icon. For this example it's not completelly necessary cause it's very specific but assume the icon left-arrow. On Fontello you can see there are dozens of icons with that exactly same name. So, if the user wants to use another Icon set from other library together with Fomantic icons, it would create lots of problems. To prevent that, if Fomantic icons where prefixed with fui- this problem would be gone.

[hammy2899]

@batata004

But then what is wrong with class="amer-sign-lang-icon"? Why do you want to use space instead of -?
SUI/FUI doesn't have - in any class names because the whole point is for the class names to be semantically written.

Also we wouldn't prefix the icon names because the element would be

<i class="ui icon" data-icon="user" />

So it would already be namespaced to FUI.

[batata004]

@hammy2899 Ah ok! But I still like most the prefix idea than creating a whole new attribute. Also, I dont like spaces used inside names.

The main reason spaces may create lots of problems is this:

<i class="ui icon" data-icon="x y"></i>

If for many reasons you need to select that element with jQuery, you could do this:

$("i.ui.icon[data-icon='x y']")

However, if your HTML becomes (which visually is exactly the same):

<i class="ui icon" data-icon="y x"></i>

That jQuery selector will not work anymore! The same is NOT true when using classes cause if you have:

<i class="ui icon x y"></i>
or
<i class="ui icon y x"></i>

the code below still would work fine:

$("i.ui.icon.x.y']")

Imagine an icon named "arrow left" if the user changes his HTML to "left arrow" the icon still would work but if you use "data-icon" and if you have selectors based on icon name, you could get into problems.

[ColinFrick]

@batata004 That's exactly what semantic / fomantic ui stands for!
arrow left is not the same as left arrow

Semantic UI treats words and classes as exchangeable concepts.
Classes use syntax from natural languages like noun/modifier relationships, word order, and plurality to link concepts intuitively.

[batata004]

@ColinFrick I agree with what you said but it does not hold true. Open https://fomantic-ui.com/elements/icon.html and look for the icon angle double left. Change it's class (using F12) to double angle left and the icon still works flawlessly. So, clearly to me, Fomantic is not enforcing it's concepts intuitively cause it accepts change of word order. If that is the case, I see no point in using spaces since using - with a prefix would allow better compatibility with other icon libraries and would avoid the problem of the selector I showed you a PoC.

[lubber-de]

Anyway : implementing dashes instead of spaces aswell as moving the icon names from classes to a data attribute is a breaking change in both cases which would require everyone to change their code.

[hammy2899]

@batata004 This is one of the reasons we want to make this change, it can allow use to be more specific for the order of words and like @lubber-de as said no matter what option we picked it would be a breaking change which would result in everyone changing their codebase.

Also word order does matter in some places in SUI/FUI https://jsfiddle.net/usq950t8/

[batata004]

@hammy2899 yeap, word order sometimes* work and sometimes* doesnt. I think inconsistency should be avoided always. As @lubber-de said, one way or another, changing the way icons work will break things.

I will just leave my last effort to advocate to using prefix with -. In many projects I still have to use external icon sets cause some of my customers want to use very specific icons. Everytime I work with icons (like font-awesome, fontello...) the sintax is always the same: prefix, '-' and the HTML is also the same. Icons will always look like:

<i class="fa-arrow-left"></i>

BUT with the new propposed change to FUI, in some websites I will have to use

<i class="fa-arrow-left"></i>
<i class="ui icon" data-icon="arrow left"></i>

This is very different. I will have to use a different "HTML structure" in case I want to use FUI icons or in case I want to use different icon sets from external libraries.

I think, from the developer point of view, it wouldnt be nice at all having to maintain 2 very different HTML code just to show icons. I am not even mentioning JS cause if FUI adopt a new format to show icons, it is gonna have an impact also in Javascript selectors.

IMHO FUI should move along the trend in this specific case cause it may be very common to people using external icon sets with a "standard code structure" and it wouldnt be nice to have different HTML, CSS and JS code just to handle FUI icons.

[hammy2899]

@batata004 A big part of developing v3 for me is to stick to the original goals and design of SUI, trust me I have done not hours but days of research into SUI and the background of the project for the sole purpose to keep to the original goals which @jlukic had when developing the library. I didn't just decide randomly to change how icons are implemented just because I can I did it because there is a need and I thought about other possible solutions but others like the one you suggested don't give the advantages of changing to a attribute. Look at tooltip it uses an attribute now you might argue that its because its the only way to achieve that effect but I would argue that moving the icon name to an attribute is the only way to achieve the effect we want for v3.

You have to understand that the changes we propose are not just randomly thought of and thrown out for people to talk about. We discuss these changes before hand and we do a lot of prototyping and research into other ways we can achieve changes without breaking the current API.

Another point is we aren't the first and won't be the last library to introduce drastic breaking changes in a new major version. For example look at angular v1 vs v2. These changes have to happen to libraries otherwise they won't improve.

---

About the JavaScript, there isn't much to change https://github.com/fomantic/Fomantic-UI/search?l=JavaScript&q=icon

[batata004]

@hammy2899 I can tell you for sure that I spent a few minutes thinking before posting here, so your thinking of hours/days is surely way more valuable than my tiny effort. I am pretty sure that whatever decision you take is gonna be the best one! I agree with the popup you said too.

Regarding JS I didnt mean about changing the way it works. I meant about how selectors would break sometimes. I will quote what I meant.

The main reason spaces may create lots of problems is this:

<i class="ui icon" data-icon="x y"></i>

If for many reasons you need to select that element with jQuery, you could do this:

$("i.ui.icon[data-icon='x y']")

However, if your HTML becomes (which visually is exactly the same):

<i class="ui icon" data-icon="y x"></i>

That jQuery selector will not work anymore! The same is NOT true when using classes cause if you have:

<i class="ui icon x y"></i>
or
<i class="ui icon y x"></i>

the code below still would work fine:

$("i.ui.icon.x.y']")

Imagine an icon named "arrow left" if the user changes his HTML to "left arrow" the icon still would work but if you use "data-icon" and if you have selectors based on icon name, you could get into problems.

[jamessampford]

For this, when using SUI I simply removed all the icons from the CSS file and used them straight from Font Awesome so essentially I could use and everything works fine and I could/can update Font Awesome independently of SUI

Personally, I think we should be able to use any icon set we want, be it Font Awesome Free or Pro, Google Material Icons, and so on, or even a subset of icons to improve loading times but still use the format, where X is the icon set's own class name so we could, if need be, refer back to the original docs

I have Font Awesome Pro, so it would be great to simply drop in those files and simply use them "out the box" without any modification to FUI

[hammy2899]

@jamessampford Technically you can use any icon set with SUI/FUI as long as you want to put in the work to modify the icon.overrides file which I agree is a big task. Maybe we could think about making a package for multiple icon sets in v3.

• @fomantic/icons-fontawesome
• @fomantic/icons-materialui
• @fomantic/icons-feather

Feel free to suggest more

Also we have a script which you can use to use FontAwesome Pro with SUI/FUI and you can update the icons easily https://github.com/fomantic/icon-script

[hammy2899]

Note about merging back into SUI & clearing up some confusion

I have saw a lot of people discussing in other repositories etc. about how FUI no longer has the intention to merge back into SUI. I want to clarify this is not true but merging back into SUI will be under different circumstances because of the changes we will be making with v3.

As I mentioned in this comment I have done lots of research about SUI and with v3 I want to keep to the design choices and ambition that @jlukic set when he started the project. I think people are misunderstanding what v3 is all about, v3 consists of 2 key points

1. Refactor/reorganize
2. and Modernize

Refactoring and reorganizing mainly comes down to the project structure itself and shouldn't affect users. Refactoring will be the build system and JS rewrite and could also consist of a CSS/LESS refactor. Reorganizing will be changing the repository to a monorepo and publishing the components as individual packages. The biggest change from the refactor will be the JS implementation which we have said a few times we will provide a polyfill for v2 to v3 to help with migration.

Modernizing the project will be simply changing aspects of the project so they are up to date with modern standards like ES6 for instance.

Now with all these changes yes the library will appear completely different compared to SUI but the underlining philosophy of the project will still be the same and hopefully it will be something @jlukic accepts and maybe agrees to how SUI should be built.

I want to point out 2 specific requirements/goals @jlukic wanted when he made SUI. He didn't want it to be like every other framework which required users to include the whole library he wanted SUI to be collection of components which users can pick and choose from, he describes this like a buffet of components. Now yes you can do that with SUI right now but it gets messy with components depending on other components etc. v3 can help with this because we can restructure the project so the components can be dependent on each other but so the user doesn't have to download and work out what they need to install to get components to work. Take the sidebar for example, it relies on the transition module which a user has to download for it to work. We can change this so the sidebar component includes the transition code which is required for it to work.

My second point is the @jlukic made the theming in SUI based on three levels of inheritance which consists of the default theme as the base layer and then a packaged theme so a theme shipped with SUI or one you download and then the site theme which is custom variables specific for that site. Now I think we can all agree that theming is a huge PITA and sometimes requires more work then its worth. Now for v3 we have a separate issue discussing theming proposals which would allow for the same three levels of inheritance but make it a lot easier and less time consuming to do.

---

Hopefully you now have a better understanding for why we are doing v3 and what the benefits are for both SUI and FUI as a whole.

If you have any questions feel free to ask 🙂

[alexandrtovmach]

@hammy2899 Thanks for clarifying all points, and yeah I have a question: How can I help?

[hammy2899]

@alexandrtovmach If you want to get involved the best way is to start helping with the issues and making some PRs, if you want to help with v3 I would highly suggest you join our discord server so we can chat 🙂

[jamessampford]

@hammy2899 I'm thinking more on the lines of having an /icons/ folder where the critical icons for things like arrows for dropdowns, etc, can be put, and should be stripped down to the absolute minimum. An icon building set could be used to build variations of the minimum if a developer really wants to change the critical icons.

Then the developer simply just needs to include a standard stylesheet declaration in the header to pull whatever icon set them want from a 3rd party CDN or from files uploaded to the server - giving total flexibility and not needing to wait for the framework to update the standard set, as well as not needing to learn a different syntax from what they're used to

The added benefit being that a developer may want to use a customised subset of icons, or may not even want any icons at all (not likely, but you never know!), so makes the whole system more flexible

Also doing it this way can help remove some "issues" around "please update XX icon set", by all means can recommend using Font Awesome but point people to FA to get the files

[batata004]

@jamessampford Font Awesome Pro is great but have you tried Fontello? Is free and works much easier, you can pick specific icons and it will generate you the subset of icons to download and embed on your page. I think you might like :)

[jamessampford]

@batata004 yes, have tried that one too ... having all these choices and subsetting is certainly useful, which is why, I think, should try to keep critical icons to a minimum, so we developers could potentially use any icon sets without really needing to modify the core framework

[mikejf-pr]

We actually use a custom icon set as well, and we've established CSS so that it's compatible with SUI and the common icons like 'icon dropdown' are supported, in addition to our common notation ('icon i-dropdown')

[bborn]

+1 for a theme builder. Have you looked at https://github.com/openmastery/semantic-ui-theme/tree/feature/2 ? Looks like they started building one for SUI but then abandoned it.

[hammy2899]

Last chance for your feedback to be heard, we will be closing the v3 survey tomorrow so if you haven't already completed the survey and you want to help out you have 2 days left.

https://www.surveymonkey.co.uk/r/398M9YJ

[Ray-B]

In on the survey in the nick of time.

Also wanted to expressly offer my gratitude for what all of the contributors on this project have been doing. Semantic UI is great and the work here is only making things better. Thank you!

@hammy2899 Have you had any discussions with levithomason over on semantic-ui-react about how to establish some parity? Right now I've just been building out components, and implementing JS when the react project is missing something that fomantic has, but I would love to see things line up. Perhaps a loaded question...

If you and levithomason had a preference, how would you two like to see something like that achieved?

[douglasg14b]

Out of curiosity, has there been any consideration for utilizing the nested capabilities of LESS for v3? I feel like there is a lot of improvements to readability and modifyability that's missed by not utilizing that...

[hammy2899]

@Ray-B There is was an issue opened over on the react project about switching to FUI, you can check it out here https://github.com/Semantic-Org/Semantic-UI-React/issues/3397

I added my 2 cents about the topic yesterday, hopefully that answers you question. Feel free to ask any other questions you may have 🙂

@douglasg14b We will most likely use nesting when implementing the theme scoping mentioned here https://github.com/fomantic/Fomantic-UI/issues/441 but we will also probably be using it in general to help with the general codebase.

[thiscantbeserious]

@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

I don't think Unit-Testing is that pointless in general even - or especially for UI.

I can't count how often I would've missed stuff if it wasn't related to my countless Unit-Tests that I've written (currently 300 and counting for our UI-Framework). Heck I even test DOM-Manipulation and CSS-Styles (like is this button clickable anymore? ... saves so much time in the longer term).

I'd vote for Jest ... and would even help writing them (via PR or whatever) :)

https://jestjs.io/en/

[4val0v]

I also want support for Angular _(desirable TS)_ + ivy support

[wdmeeste1]

Awesome to see this switch will happen. Any idea when the first test version would be released? Timeline?

[hammy2899]

@wdmeeste1 I have mentioned this in a few places now but lets make it official.

Official development on v3 has not started yet we are still doing early prototypes and figuring out any road blocks we need to overcome. I have a document with ~5 major road blocks we need to figure out before we can start the actual development process.

Now that being said once we do start the development process there won't be any alpha/betas for a long time if we started development today (17/07/2019) we most likely won't release a public alpha/beta for maybe about a year since there is a lot of work to be done and I want to try and keep the initial work of v3 within the FUI team since we can communicate a lot easier which will lead to more feature filled betas and a better code base.

The actual release of v3 won't be for a very long time if I was to put an estimate I would put it in 2021, remember that would be the full v3 release with all features + more in the current library and implementations for ~4 frameworks which again... is a A LOT of work.

[Aniel]

@hammy2899 regarding the implementation for 4 frameworks. Is there any news, regarding the proposal from @levithomason on working with the folks from stardust-ui?

See https://github.com/fomantic/Fomantic-UI/issues/319#issuecomment-457000595 and https://github.com/fomantic/Fomantic-UI/issues/319#issuecomment-457022665

[hammy2899]

@Aniel Not much has happened after our call with the Stardust team but that is down to a few reasons mainly being they are quite far into their development and since we are still in the prototyping/planing phase we don't know what we want exactly (if you understand what I mean) and I think we jump too soon and after a lot of messing around stardust might not be the right move for us going forward.

[wdmeeste1]

@hammy2899 Thxs for information ;) No pressure, just curious :)

[GammaGames]

What about porting grids over to the css grid layout? I've only just learned about it, but the layout seems flexible and like an improvement over flexbox. It even has decent support.

It might require the user to set some data-weight attribute or something to make it more flexible than the current 16-wide grid.

[hammy2899]

@GammaGames I have mentioned CSS grid in a few places and I am considering it but there is more to look at then just browser support.

[YamiOdymel]

@GammaGames I've tried to replace the Semantic Grid with CSS Grid, but it's not flexible as Semantic Grid.

For example you cannot use reversed grid or left floated, right floated columns since CSS Grid is kinda like a "Fixed Layout" which turns your <div>s into a grid system instead of flexible boxes/containers (_I don't know how to explain this feeling_).

I don't think it would work if you are trying to make a flexible layout framework based on the CSS Grid.

[certainlysylvia]

I've been working on a massive project for a few years now with semantic being deeply integrated. We're a small dev group so could not possibly solve the finance issues - so here we are now.

atm we're deep in back end stuff - so we cannot directly contribute here, yet but in time we aim to dive in. I personally love the direction fomantic is taking, with a few reservations.

So here are our thoughts re the many discussions and roadmap points we've trundled through

1) Completely agree with ES6 implemetation. The javascript issues can be resolved by tooling Babel on the development end. This way, you can write everything in ES6 (or 7 or 8 or 9 later etc) and have an automated process to transliterate to ES5 and browser-specific code / polyfills -- and even to typescript and such to some degree. You could even have a JQuery compat version in the output code libraries.

People could then download the code library they prefer to integrate with. Woo.

2) Can we have a serious discussion about whether we continue to develop with the aim to eventually reintegrate with Semantic UI? Because this could limit possibilities - and unless anyone has heard anything from @jlukic regarding this and given the time that has passed and no sign of any serious maintenance (even ssl at semanti-ui is down) ... well really, is that goal still essential? I have huge respect for Jack but we need to consider realities here. This said, I am not implying we should move away from the core of Semantic UI - with regard to how it cleverly structures css et al. Even Semantic Theming was at a point pleasing to us. But we should discuss what breaks might make re-integrating too difficult and then ponder the pros and cons from there.

3) If you guys need an assist with a centralised dev centre (if one is not already in place) give us a should and we'll be happy to whack up a Phabricator Portal for all (custoim hosted of course) - unless of your you have other stuff already in place. We use a Phabricator Portal ourselves and it's an awesome and easy workflow - and yes, it can work alongside github too :D

3) Apologies if this is too forward or out of bounds ... but are there any official funding setups yet? - Finances and such? Any organising beyong chat areas and/or here?

4) I know -- rather rude of us - to leap in and start poking like bossy types -- but we really aren't bossy at all, just aiming to sort some clarity and see if we can help out with organising --- if not yet the code :smile:

So year -- more details about us and backgrounds and capacities etc later (hint; we have everything from server experience to back and front end code in multiple langs so hopefully we can help out somewhere - oh and a fair bit of agile and devop stuff too.

We think the progress here so far is awesome! The path forward also looks awesome :wink: - so lets be awesome together.

Kate out ..

[ptejada]

For the multi package in monorepo idea i suggest looking into https://lerna.js.org/

For the static site genrator check out https://gohugo.io/

[goodwin74]

Thank you very much for the development of the project! Hello from Russia!😉

We have already switched all projects to Fomantic-UI 👍

[hammy2899]

@certainlysylvia We currently just use GitHub and Discord for planning and communication, we don't need nor do we want more places for such activities because it will add complexity for new contributors and its more things to manage. Also we try to keep everything in the open and not keep plans etc. hidden from our users which is why we use GitHub for our planning.

However thanks for the offer 👍

---

@ptejada I am currently using lerna in my prototypes and hugo is on my infinite long list of static website frameworks we could use for the docs 😅

[tomByrer]

I personally find monorepos in general hostile to newbie contributors; all those folders are a maze. Fine if you expect only a core team to contribute.

I've used Hugo, but I'm more enamored by GatsbyJS. Good speed to develop with, website output is fast, VERY good ecosystem (plugins, themes, etc). Built around ReactJS & GraphQL, but has plugns to use markdown & other data sources as input. Decent sized paid staff, so solid support. There is a few Semantic-UI themes as well.
Docz uses GatsbyJS, so that is a good place to start IMHO.

[hammy2899]

@tomByrer GatsbyJS is also something I'm looking at and I have also messed around with it and it seems a good candidate.

About the monorepo, I don't think it will be as confusing like other projects and it will hopefully be quite straight forward for any new contributors. My current prototype which is likely the future base of v3 does not have a maze of directories and is quite simple to find your way around. I think at some point we will have documentation for contributors to help combat this issue since no matter how simple the repo is it will always seem hard to get into for new contributors when looking at all skill levels. That being said contributor docs most likely won't be a thing once v3 is released but as I said it should be something we look into doing in the long term.

[0xF6]

How do you like the idea of adding implementation to plans for Blazor Components? 🤔

[Daniel127]

@0xF6 I'm implementing semantic components for Blazor, when it's finished I can continue with a fork for Fomantic.

[271ch]

1. FUI v3.0 2019 means that FUI v3.0 will be released in 2019?
2. Is the library implementations of vue.js listed in the v3.0 Road Map something concrete? Is there already some code?

[hammy2899]

@271ch Yes a first party library for Vue will be shipped with v3.

Me and a few members of the core team are having a call this week about v3 which will hopefully push its development forward some more. I can't confirm when v3 will be released but it is most likely not 2019 because there is a lot of work to be done and we are only a small team.

[bornemisza]

Can we include some great utility into Fomantic UI in near future?

Bootstrap having a spacing utility (https://getbootstrap.com/docs/4.3/utilities/spacing) which is very useful thing in ui stack. I love to work with fomantic ui, honestly more then bootstrap, but boring to implement custom css for every project with this little things)

I think it would be a great new feautre to use something like that!

[hammy2899]

@bornemisza This has already been requested (https://github.com/fomantic/Fomantic-UI/issues/22) and it will be getting added for v3

[batata004]

Just wondering if there is already any alpha version we can test of v3? Very anxious!

[hammy2899]

@batata004

Official development on v3 has not started yet we are still doing early prototypes and figuring out any road blocks we need to overcome. I have a document with ~5 major road blocks we need to figure out before we can start the actual development process.

See https://github.com/fomantic/Fomantic-UI/issues/319#issuecomment-512185785

The only change from this comment is me and a few team members have had a call and we are moving forward with a repo which they are getting familiar with. This could mean early development could start in the next 2-3 months.

[bartocc]

@hammy2899 I believe you meant to mention @batata004

[hammy2899]

@bartocc Oh yeah sorry 😄

[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.

[dutrieux]

I love you team fomantic ui, thanks for your explanation and good luck with the hard work ahead of you : I am wholehartedly with you ❤️❤️❤️

[bborn]

☝️ ditto. Super excited that official Vue support is coming.

[brunotourinho]

I can't thank you enough! I really appreciate your work and the community you've built. I'm currently using FUI in production and looking forward to the VUE version.

[ansarizafar]

Why not support Svelte?

[hammy2899]

@ansarizafar Svelte is on the list of possible integrations but as I said DOM, React and Vue are the libraries we will ship with the release of v3. We actually have a few other libraries we want to make first party integrations for however we don't have to time to make these for the release of v3 which is why they will come after.

[Polve]

Great work and roadmap guys.

The only thing I miss so much is official ember support :-(

[ansarizafar]

@hammy2899 Thanks for the clarification. Svelte is missing from the list in the road map https://github.com/fomantic/Fomantic-UI/blob/master/ROADMAP.md#library-implementations that is why I have asked about it here.

[hammy2899]

@Polve Ember is also on the list of possible future integrations.

@ansarizafar The roadmap isn't up to date because of all this new information, I will be updating it some point today.

[DepaMarco]

@hammy2899 (and the others devs) Really thanks for this "wall of text". I really appreciate the way you try to involve the community, so again thanks for this and to invest your free time in a project useful to many people.
I look forward to the announcement of the new release announcement of the new release.
Have a nice day.

[douglasg14b]

@Polve I'm not too familiar with other frameworks, but can't components be imported in frameworks like Angular, Ember, React and what not? Like they can into Vue?

Ie. I can write a Vue component, export it from Vue as a web component. Then import that into Angular.

[Polve]

@douglasg14b I'm sorry but I'm not familiar with the technical details on how to create a project like https://github.com/Semantic-Org/Semantic-UI-Ember but for fomantic.
That's what is needed for ember developers though

[hammy2899]

@Polve Looking at that repo a lot of it could just be boilerplate and the only SUI stuff is in here https://github.com/Semantic-Org/Semantic-UI-Ember/tree/master/addon and that doesn't look too bad and might be able to use the DOM integration for basic usage until we did a proper integration.

[douglasg14b]

@hammy2899 For the Vue portion of the library, I would highly recommend that you look at the "Vue way of things", which is a failing a lot of UI libraries make when producing a Vue package. Not utilizing Vue's functionality for the Vue library, and making it easy to slick to sue within that ecosystem.

I would recommend Vuetify as a good resource/codebase to check out. Or just have one of your maintainers/devs write a non-trivial vue application (After taking some free Vue courses to get a quick intro).

This is assuming you don't already have a Vue dev on your team...

---

I only wish my day job wasn't in crunch mode for the last 3 months due to an influx of clients, this is the kinda project I'm salivating to contribute to.

[donaggio]

I know that it has already been decided and even discussed before (I already raised this issue) and I'm not against ditching jQuery for a plain DOM integration, but I would like to know if there are any plans to support a jQuery-compatibility layer, at least for the first fiew v3.x releases. This would have the benefit of letting already deployed projects to have an easier migration path to FUI (or whatever will be its future name) v3.0.

[hammy2899]

@donaggio The comparability layer is discussed in this comment https://github.com/fomantic/Fomantic-UI/issues/319#issuecomment-559211853

[crewow]

any good news about V3

[RedhatPH8]

How can we (the community) help? And should we be using the RFC repo? https://github.com/fomantic/rfcs

[kushthedude]

@hammy2899 Any chance to have an ember library by release of 3.0 ? As Semantic-UI-Ember is definitely missing quite a lot of features.

[guntribam]

Please support Svelte!

[prudho]

3.0 will be released first with vanilla JS support, then React and Vue will be added later. I'd like to see other frameworks supported as well, but we should start slowly... we're a small team of 5 contributors working on FUI for free, on our spare time.

[maidzen]

tbh. the community should provide wrapper for more frameworks after release, React, Vue are the most used frameworks for new web apps, so initial support ist important to be a relevant framework.
They also provide the example on how to implement framework support.

But for frameworks like Svelte, Ember etc. the community should come in and create the compatibility layer.
The new design of FUI v3 allows this to be "easy" (compared to now) and should only take time of the core contributors if some core problems happen while creating the layers.

This is, in my opinion, important so you don't end up working half the time on Framework problems instead of having the time to improve FUI.

[Aniel]

I think the call for numerous integrations with other frameworks shows that maybe the best approach would be to use Web Components. All major frameworks, of my knowledge, support the inclusion of such components. To help ease the development Stencil or something similar could be used. Or does the abstraction layer mentioned in https://github.com/fomantic/Fomantic-UI/issues/319#issuecomment-559211853 make the creation of Web Components easy? Then maybe a Web Components "integration" would reduce the overhead of supporting multiple frameworks.

See the Stencil framework integration documentation for examples on how to enable the use of standard Web Components in multiple frameworks.

[hammy2899]

We (core FUI team) had a meeting at the end of last year and discussed some more about the future of Fomantic which led to some critical decisions being made which will carve the future direction of the framework development. I don't want to disclose these discussions at the moment as it's early days however it will help make these third party integrations more organised and kept to a standard which we would be happy with. These decisions were ultimately made to help with future plans for Fomantic as more then just a framework.

@Aniel The abstraction layer and our new plans will make it incredibly easy to build a Web Components integration and I'm sure that will be something which gets developed as more developers are starting to learn and use them. We won't be building the core framework or the abstraction layer on Web Components because this would actually restrict us for some future plans.

[murbanowicz]

We (core FUI team) had a meeting at the end of last year and discussed some more about the future of Fomantic which led to some critical decisions being made which will carve the future direction of the framework development. I don't want to disclose these discussions at the moment as it's early days however it will help make these third party integrations more organised and kept to a standard which we would be happy with. These decisions were ultimately made to help with future plans for Fomantic as more then just a framework.

@Aniel The abstraction layer and our new plans will make it incredibly easy to build a Web Components integration and I'm sure that will be something which gets developed as more developers are starting to learn and use them. We won't be building the core framework or the abstraction layer on Web Components because this would actually restrict us for some future plans.

When and where can we expect some information?

[hammy2899]

@murbanowicz I can't say an exact date however when we announce anything we will post it here.

[crewow]

Great

[devopg]

wait vue ❤️

[lucaguada]

We won't be building the core framework or the abstraction layer on Web Components because this would actually restrict us for some future plans.

@hammy2899 what kind of restrictions are you going to meet by developing FUI with web-components? just asking for the sake of curiosity, since I just started to learn something about them and they look pretty promising and easy to understand even for who knows a little about frontend development :)

[hammy2899]

@lucaguada Unfortunately at the moment as its still not confirmed I can't say much but I will say the restriction is with what else we can use the abstraction layer for rather then a restriction with web-components.

[qJake]

Hello FUI team,

First, thank you for continuing this project. We found the news about SUI/FUI and transitioned to FUI (2.3.x to 2.8.x) nearly seamlessly (no breaking changes in our projects). Awesome!

I wanted to make sure that you knew that there are people that still just want to include fomantic.css and fomantic.js in their projects (yes, with all of the components loaded) and be on their way. I know there are a lot of frameworks and integrations and components and modules and all that fun stuff, but please remember to also keep support for just the basic single CSS/JS file included via a CDN, that allows for basic usage of the FUI library at the end of the day. This will make a lot of FUI users happy. 🙂

Thanks!

[leouofa]

Thanks for moving the project forward 💪

[bakeiro]

Hi there
just wanted to know the status of the FUI 3.0, is there any progress on this? what can we expect? is the project going forward with the 3.0?? just to know the status..
btw nice project!

[hammy2899]

@bakeiro Yes v3 is happening however we need to complete a new project before we can officially work on FUI v3. More news about this in the coming weeks.

[lpar]

I'd just like to note that lack of accessibility is a massive legal minefield in the US, thanks to case law regarding the Americans with Disabilities Act. So the "Enterprise Ready" description on the web site is probably asking for trouble until the accessibility issues are fixed. Good luck with the fork though!

[pixobit]

Is v3 still in planning process, or it's been started already?

[bornemisza]

@hammy2899 @lubber-de @prudho any update/news? Community is on hotline about v3. 😃 🙏 ✌️

[hammy2899]

@brunotourinho @pixobit @bakeiro @batata004

---

I have said from the start of this project that I would be fully open and we would remain community focused so I am going to live up to that promise and provide you with possibly the biggest update since the announcement of v3.

When I first made the v3 announcement public we had the goal to complete that project within 1-2 years with the current maintainers which was 4 at the time. This was a huge goal in itself however I can confirm A LOT has changed since then. The v3 plan has changed at least 5 times drastically since the announcement. I would argue these changes are for good however this also added a lot more work which we couldn't achieve with the amount of maintainers we had. You have to also understand all maintainers (currently 6 now) have full time jobs and we work on Fomantic in our free personal time.

So after all this time what has changed and where are we at now?
Well at the start we wanted to rewrite the library in a more module and modern way however that soon changed to a more component based approach however with the increase in front end frameworks in recent years we understood that this wouldn't work in the future so we moved onto a new approach which was the agnostic layer which would be the foundations of the framework and would allow us to build libraries for specific front end frameworks etc. again this changed.

This is when the light bulb moment happened and we were in a position to make a change to the industry on a larger scale and I think the majority of people reading this will agree that there is no "standard" way of designing or developing a website when it comes to the components used. What I mean by this is we have mass amounts of different UI frameworks all with the same and different components to use however they all work slightly differently which in turn can lead to confusion for the user. This is when I first started the idea of creating a UI spec focused on the usage and interaction of UI rather then look and feel of UI which most specifications currently do and we would build Fomantic v3 on top of this spec however again this quickly became a larger task then we first thought and once again we didn't have enough people or resources to do this. I want to add that this UI spec wasn't just a simple specification on how web components would work, you may have saw me talking about more then just web components in past comments this is what I was talking about. We could make this spec be a generic UI spec meaning it could be used on the web, mobile, desktop, TVs and even car screens it would be a universal spec for how components would allow users to interact with them. This would also make it a lot easier for developers to write these UIs as it would all work the same. Now you might be thinking why would anyone use a UI which is the same as everyone else, well they wouldn't this spec would be specifically for interaction between the user and the component and how the component managed itself for example its state. The look and feel could be anything so all current UI frameworks from Fomantic, UIKit, Material UI, Bootstrap, Ant Design etc. they could all follow the spec however still have their own look and feel. This spec was precisely to make a unified catalog of components which could be used everywhere and no matter where the user saw the component they would know how to interact with it.

So where are we now?
Well once again plans have changed, we have decided to start designing Fomantic v3 as standalone library and use that library as the base of this spec we want to create. Like everything I have talked about this will take time however I want to get this into the public this year so the community can also help. You might also be thinking if we are fully open and community focused why don't we just open it up now? Well we don't want to open it fully as we believe it will be a lot easier to get v3 off the ground in its early stage when we control it in its entirety.

---

I also want to make clear for everyone who is maybe worried with the changes we are doing that they may not get the implementation they want whether that be React, Vue or standard standalone JS/CSS we will not forget about any implementation and our intent is to build the library in such a way that it can be used in anyway possible.

---

I also want to add that v3 definitely has slowed down this year as I am personally the main member working on its planning etc. and a lot has changed within my life this year specifically which means I can't work as much on the project however I am still determined to get v3 and Fomantic finished 🥰

[batata004]

@hammy2899 I appreciate your kind work and of other devs of this awesome library! But I will be really honest: v2 is becoming, at every new release, much better, much more customizable (using build options) in such a way that now I can pretty easily reduce the library size in 95% for some projects I use Fomantic! I can build only the components I want AND also there is a high granularity control of what I can decide to use inside most components. Take for example the effects of the transition component: now is pretty easy to select only the effects I want and drop anything else I dont need. I cant see how much better v2 could become, it's already a pretty pretty reliable, optimized and good performance library!

I dont know if it's worth so much trouble going to v3, since v2 is already doing a great job and maybe focusing more in make v2 even more customizable is the way to go, in my opinion!

[hammy2899]

@batata004 v2 is not slowing down, currently I am the only one working "full time" on v3 and everyone else is doing v2 and helping with v3 when they can.

[batata004]

@hammy2899 I didnt say v2 is slowing down, that's why I suggested keeping focused only on V2 since it's pretty good at this point. Lots of component customizations on building and lots of bugs already fixed. Anyway, if you are willing to take this big step up to V3, it surelly will just add more capability to this awesome project!

[maystro]

Please Consider RTL languages , will be great

[darlesson]

The Browser Support section for V2 includes IE11, the Legacy Edge on Windows and iOS Safari 7+.

The major changes and the new components lists in the roadmap mention the use of actual CSS grid for the Grid component and CSS properties for V3 instead preprocessor variables.

Even though the roadmap mentions "Browser support for all major browsers and IE11", it's not clear how the changes above could work with IE11, old Edge and iOS Safari 7+.

It would be nice to keep support to preprocessor variables and expose the CSS variables for those who can use that. Also it should be beneficial to have a flexbox component for older browsers if changing grids to CSS grid is official.

Personally I would drop iOS Safari 8-, keep the last 2 Edge versions (on Chromium) and keep IE11 as so many companies still depend on it.

I would like to know from the maintainers whether we could have a clear path forward for browser support.

[lubber-de]

I personally would also drop IE11 support. If someone really needs to develop a new website which must run on on IE11 they should use v2. Same for old edge.
But this is only my personal opinion

[pixobit]

I personally would also drop IE11 support. If someone really needs to develop a new website which must run on on IE11 they should use v2. Same for old edge.
But this is only my personal opinion

Agree 100%

[darlesson]

Fomantic for V2 means jQuery only. The Semantic UI React solution is not enough to justify Fomantic and Semantic for companies that need a serious commitment on a library. If IE11 should be dropped, then the community should know sooner in order to better decide whether they can keep using Fomantic.

Just to clarify, the React implementation for Semantic is great, but the 2 years of no evolution on the Semantic UI side is not helping.

[pixobit]

Fomantic for V2 means jQuery only. The Semantic UI React solution is not enough to justify Fomantic and Semantic for companies that need a serious commitment on a library. If IE11 should be dropped, then the community should know sooner in order to better decide whether they can keep using Fomantic.

Just to clarify, the React implementation for Semantic is great, but the 2 years of no evolution on the Semantic UI side is not helping.

For any company that is planning to be using Fomantic V3, and needs support for IE11, knowing the drop of jQuery and move towards ES6, should be huge red flags already on their own, no matter if they will keep it or no

[lubber-de]

Well, if a company these days decides a _new_ webpage _must_ run under IE11 without any allowed second browser , then also jquery shouldnt be a problem for them, honestly.
I also work for a company who still use IE11, but only because some old legacy ancient business sites like SAP generated websites or BMC Remedy was never updated to run on modern browsers. We use Chrome as second browser for everything else and daily browsing usage. I only have to touch IE11 once a month when booking my hours in SAP.

For a completely new website today (where also the usage of react/vue/angular/etc seems legit making use of modern techniques that IE11 does not support) even nowadays companies have a second browser installed on their machines)
Also performance wise this would be the better decision.

[darlesson]

As a roadmap issue, what is the verdict in this matter? I just wanted to point out the contradiction on the IE11 support versus features that cannot be polyfilled for V3.

[lubber-de]

There isn't any final decision. In the end it is all about maintenance effort.
IE11 support is only marked as planned

Move SASS variables to CSS variables

means to support both. Basically preprocessor variable logic will be kept but turning them into CSS variables is an optional step.
And that would also solve the "Safari 7 / Legacy Edge" issue
[Edit] iOS 9.3 (which is needed for CSS variables support) is available down to iPhone 4s. This should be enough to support IMHO)

[WanderQing]

This is amazing, I can't wait to use it!!!

[hadnet]

How about @types status on this v3? Currently we need to use the workaround @types/semantic-ui (but it's so old!).

[adamnieto]

Thank you FUI team for all of your work and contributions!

Sorry if I am late to the game but just wanted to verify.

Is there a plan to eventually use Microsoft’s https://www.fast.design/ to help build future versions of semantic/fomanitc? Looking back at the history of this issue I speculate that @levithomason was referring to FAST in this comment? Looks like using FAST would allow us to write the UI library once and support multiple JavaScript frontend frameworks via integrations.

P.S. take a look at this section on how FAST can help. It mentions how you can use FAST to implement Google’s Material Design or Twitter Bootstrap. Perhaps we can do the same with Fomantic.