The future of Fomantic as v3.0
y0hami opened this issue · 234 comments
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:
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)
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.
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. 👍
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.)?
@donaggio We could think of some kind of adapter-system where you can choose if DOM manipulation should be done by familiar old jquery function names, internal/native ES6 functions or even a new virtualDOM system like for example https://mithril.js.org/ uses.
That would probably still mean to always use wrapper-functions. 🤔
We have to discuss this further. There are always pros and cons. That`s why we will hear your voice 🙂
@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.
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.
@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/utilswill 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)
@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.
@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.
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.
@singhda8 Semantic-Org/Semantic-UI#6693
Based on this, and on SUI for React, I believe the way to go is forking as needed. With the planned removal of jQuery, I think FUI wants to be library-agnostic, using pure JS. Which is the way to go, if you ask me.
@hammy2899 I am very excited for this and I am sorry the intent to merge was never achieved.
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.
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.
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 UIis a typo and redirects toSemantic UIwhich means it's even harder to discover.
- Even Google still thinks
- 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.
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
I suppose there's still no interest in using PostCSS or Sass, right? You guys are sticking with Less?
@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 🙂
@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.
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.
@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.
This looks great! Please setup http://opencollective.com so we can make this project sustainable on the long run.
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
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.
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
@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.
Webpack for the build process?
I'd highly recommend https://parceljs.org as it has way better defaults and pratices convention over configuration.
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.
@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.
@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.
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.
@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?
I would recommend using upcoming SvelteJS version 3 https://v3.svelte.technology for creating small and reactive components.
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!
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".
@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).
@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...
@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.
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.
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 🙂 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 😉
@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 #319 (comment)
@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)
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, me@levithomason.com.
@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.
please also respect mine.
I definately do! 🙂 Sorry, if my comment got mislead! 🤝 We want to hear your opinion, that's why this thread was created
And i love, you guys are already testing the next version! 👍
getting rid of 2 (or 1) lines cannot be an argument to do this.
Of course! 😆
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 :-)
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.
@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
@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!
@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.
@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.
@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.
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.
@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.
@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.
@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!
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.
@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
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.
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.
@douglasg14b I agree, this thread is starting to get slightly off topic...
@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.
@douglasg14b I will sort something out 😉
@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.
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!
This sounds like Semantic-UI version of what Ionic4 is doing. Something like StencilJS might be useful. Just a note for the decision makers.
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?
@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.
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...
@murbanowicz You may look at #402 (comment) 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
@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)
To keep the topic flowing, has there been word on what @hammy2899 and @levithomason might be planning out in regard to collaboration?
@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.
@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 😞 ).
The more information the better.
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.
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?
#319 (comment)
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!
@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.
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.
@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 #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.
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.
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
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:
-
let users choose only the icons he wants to use in the semantic.json file so when the user executes the
gulp buildhe will only have a small set of icons on his final semantic.min.css file -
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.
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).
Also, every major framework that uses icons usually make it appear inside
<i />elements using theclassattribute to be used to referene which icon the dev wants to show. Usingdata-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.
@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.
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.
@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.
@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.
@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.
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.
@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/
@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.
@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
@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.
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
@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.
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
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
- Refactor/reorganize
- 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 🙂
@hammy2899 Thanks for clarifying all points, and yeah I have a question: How can I help?
@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 🙂