New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The future of FUI in 2019 and v3.0 #319

Open
hammy2899 opened this Issue Dec 20, 2018 · 74 comments

Comments

@hammy2899
Copy link
Member

hammy2899 commented Dec 20, 2018

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.

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!


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

@Atulin

This comment has been minimized.

Copy link

Atulin commented Dec 21, 2018

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

This comment has been minimized.

Copy link
Member

lubber-de commented Dec 21, 2018

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

@etshy

This comment has been minimized.

Copy link

etshy commented Dec 21, 2018

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

This comment has been minimized.

Copy link

donaggio commented Dec 21, 2018

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

This comment has been minimized.

Copy link
Member

lubber-de commented Dec 21, 2018

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

@hammy2899

This comment has been minimized.

Copy link
Member

hammy2899 commented Dec 21, 2018

@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

This comment has been minimized.

Copy link
Member

ColinFrick commented Dec 21, 2018

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

This comment has been minimized.

Copy link

donaggio commented Dec 21, 2018

@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

This comment has been minimized.

Copy link
Member

hammy2899 commented Dec 21, 2018

@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

This comment has been minimized.

Copy link

donaggio commented Dec 21, 2018

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

This was referenced Dec 21, 2018

@singhda8

This comment has been minimized.

Copy link

singhda8 commented Dec 22, 2018

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

This comment has been minimized.

Copy link

Atulin commented Dec 22, 2018

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

@princeandrew01

This comment has been minimized.

Copy link

princeandrew01 commented Dec 23, 2018

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

@romaninsh

This comment has been minimized.

Copy link

romaninsh commented Dec 23, 2018

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

This comment has been minimized.

Copy link

YamiOdymel commented Dec 25, 2018

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)

image

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

image

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

This comment has been minimized.

Copy link

douglasg14b commented Dec 25, 2018

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.
@Jncocontrol

This comment has been minimized.

Copy link

Jncocontrol commented Jan 1, 2019

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

This comment has been minimized.

Copy link

QWp6t commented Jan 2, 2019

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

@hammy2899

This comment has been minimized.

Copy link
Member

hammy2899 commented Jan 2, 2019

@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

This comment has been minimized.

Copy link
Member

hammy2899 commented Jan 2, 2019

@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

This comment has been minimized.

Copy link

wrighta16 commented Jan 4, 2019

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

This comment has been minimized.

Copy link

IsaakGroepT commented Jan 5, 2019

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.

Next one is Ionic for you then? You seem to have an issue with making a final choice.
Your focus seems to be mainly on mobile, and while SUI and FUI are taking responsive design into account, they're not "native" mobile interfaces. They remain web interfaces for now.

You mention FUI having a healthy community, but you're mistaken imo. Most of the updates in FUI seem to be the result of a few amazing devs that put and especially could put time into FUI, while the original dev of SUI ran into the issue of having a lack of time to put sufficient time into the project. FUI is a new project and it's still sprouting from the seed that SUI is, wanting to continue where SUI is stalling, while still wanting to merge the changes of FUI back into SUI when the original project can continue again at a normal development pace. You can also see that the Gitter channel is mostly silent and without activity, although that's just my conclusion from the last month.

So I'm giving you the advice to reconsider what framework you really need and stick with it. FUI and SUI are frameworks to keep an eye on, but mostly for web related interfaces for now, not what you seem to be wanting. They remain two pieces of awesome software though!

@douglasg14b

This comment has been minimized.

Copy link

douglasg14b commented Jan 5, 2019

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

@lubber-de

This comment has been minimized.

Copy link
Member

lubber-de commented Jan 7, 2019

@labby

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! 😆

@labby

This comment has been minimized.

Copy link

labby commented Jan 7, 2019

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

This comment has been minimized.

Copy link

batata004 commented Jan 7, 2019

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

This comment has been minimized.

Copy link
Member

ColinFrick commented Jan 7, 2019

@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

This comment has been minimized.

Copy link

batata004 commented Jan 7, 2019

@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

This comment has been minimized.

Copy link

etshy commented Jan 7, 2019

@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

This comment has been minimized.

Copy link

batata004 commented Jan 7, 2019

@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

This comment has been minimized.

Copy link
Member

hammy2899 commented Jan 7, 2019

@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

This comment has been minimized.

Copy link

Atulin commented Jan 7, 2019

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

This comment has been minimized.

Copy link

batata004 commented Jan 7, 2019

@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

This comment has been minimized.

Copy link
Member

lubber-de commented Jan 7, 2019

@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

This comment has been minimized.

Copy link

batata004 commented Jan 7, 2019

@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

This comment has been minimized.

Copy link
Contributor

levithomason commented Jan 8, 2019

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

This comment has been minimized.

Copy link

khornberg commented Jan 8, 2019

@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

This comment has been minimized.

Copy link

douglasg14b commented Jan 8, 2019

@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

This comment has been minimized.

Copy link

douglasg14b commented Jan 8, 2019

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

This comment has been minimized.

Copy link
Member

hammy2899 commented Jan 8, 2019

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

@douglasg14b

This comment has been minimized.

Copy link

douglasg14b commented Jan 8, 2019

@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

This comment has been minimized.

Copy link
Member

hammy2899 commented Jan 8, 2019

@douglasg14b I will sort something out 😉

@batata004

This comment has been minimized.

Copy link

batata004 commented Jan 8, 2019

@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

This comment has been minimized.

Copy link
Contributor

levithomason commented Jan 9, 2019

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 comment has been minimized.

Copy link

gaurav- commented Jan 10, 2019

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

This comment has been minimized.

Copy link

jouni commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Contributor

levithomason commented Jan 11, 2019

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

@hammy2899 hammy2899 added this to Proposal in FUI v3 Jan 17, 2019

@murbanowicz

This comment has been minimized.

Copy link

murbanowicz commented Jan 18, 2019

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

This comment has been minimized.

Copy link
Member

lubber-de commented Jan 18, 2019

@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

@murbanowicz

This comment has been minimized.

Copy link

murbanowicz commented Jan 18, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment