Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

The future of Fomantic as v3.0 #319

Open
hammy2899 opened this issue Dec 20, 2018 · 198 comments
Open

The future of Fomantic as v3.0 #319

hammy2899 opened this issue Dec 20, 2018 · 198 comments

Comments

@hammy2899
Copy link
Member

@hammy2899 hammy2899 commented Dec 20, 2018

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)

@Atulin
Copy link

@Atulin 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
Copy link
Member

@lubber-de 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
Copy link

@etshy 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
Copy link

@donaggio 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
Copy link
Member

@lubber-de 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
Copy link
Member Author

@hammy2899 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
Copy link
Member

@ColinFrick 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
Copy link

@donaggio 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
Copy link
Member Author

@hammy2899 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
Copy link

@donaggio 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
Copy link

@singhda8 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
Copy link

@Atulin 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
Copy link

@princeandrew01 princeandrew01 commented Dec 23, 2018

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

@romaninsh
Copy link

@romaninsh 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
Copy link

@YamiOdymel 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
Copy link
Contributor

@douglasg14b 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.
@Bradley-H
Copy link

@Bradley-H Bradley-H 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
Copy link

@QWp6t 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
Copy link
Member Author

@hammy2899 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
Copy link
Member Author

@hammy2899 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
Copy link

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

@douglasg14b
Copy link
Contributor

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

@domenkozar
Copy link

@domenkozar domenkozar commented Jan 5, 2019

This looks great! Please setup http://opencollective.com so we can make this project sustainable on the long run.

@Bradley-H
Copy link

@Bradley-H Bradley-H commented Jan 5, 2019

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

@pixobit
Copy link

@pixobit pixobit commented Jul 15, 2020

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

@bornemisza
Copy link

@bornemisza bornemisza commented Jul 25, 2020

@hammy2899 @lubber-de @prudho any update/news? Community is on hotline about v3. 馃槂 馃檹 鉁岋笍

@hammy2899
Copy link
Member Author

@hammy2899 hammy2899 commented Jul 26, 2020

@brunotourinho @pixobit @bakeiro @batata004


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

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

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

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

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


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


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

@batata004
Copy link

@batata004 batata004 commented Jul 26, 2020

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

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

@hammy2899
Copy link
Member Author

@hammy2899 hammy2899 commented Jul 26, 2020

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

@batata004
Copy link

@batata004 batata004 commented Jul 26, 2020

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

@maystro
Copy link

@maystro maystro commented Aug 17, 2020

Please Consider RTL languages , will be great

@darlesson
Copy link

@darlesson darlesson commented Sep 14, 2020

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

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

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

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

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

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

@lubber-de
Copy link
Member

@lubber-de lubber-de commented Sep 15, 2020

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

@pixobit
Copy link

@pixobit pixobit commented Sep 15, 2020

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

Agree 100%

@darlesson
Copy link

@darlesson darlesson commented Sep 15, 2020

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

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

@pixobit
Copy link

@pixobit pixobit commented Sep 15, 2020

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

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

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

@lubber-de
Copy link
Member

@lubber-de lubber-de commented Sep 15, 2020

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

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

@darlesson
Copy link

@darlesson darlesson commented Sep 15, 2020

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

@lubber-de
Copy link
Member

@lubber-de lubber-de commented Sep 15, 2020

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

Move SASS variables to CSS variables

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

@WanderQing
Copy link

@WanderQing WanderQing commented Oct 21, 2020

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

@hadnet
Copy link

@hadnet hadnet commented Nov 15, 2020

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

@adamnieto
Copy link

@adamnieto adamnieto commented Nov 29, 2020

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

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

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

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

@kspeakman
Copy link

@kspeakman kspeakman commented Jan 12, 2021

If v3 is going to be highly breaking and no longer merge-able with Semantic, you might consider creating a new project for it with its own distinctive name/identity.

Practically, using v3 puts users in the position of having to pin Fomantic to v2 or remember to install v2 explicitly to be compatible with what they already know and use from Semantic. Lots of projects do this with major version changes, but it doesn't make it any less painful.

Anyway, love what you are doing here. Semantic is awesome and keeping it alive is awesome. Thank you!

I recently switched to Fomantic after needing to build Semantic to change theming, and it would not build.

@maidzen
Copy link

@maidzen maidzen commented Jan 13, 2021

@kspeakman
#1125

@kspeakman
Copy link

@kspeakman kspeakman commented Jan 16, 2021

Guess I should have done more exploring. :)

@tonyChenHey
Copy link

@tonyChenHey tonyChenHey commented Feb 8, 2021

鎶辨瓑鎴戜笉浼氱敤鑻辨枃琛ㄨ揪锛岃繖涓棶棰樹笅濂藉儚鏄彂琛ㄥv3鐨勬湡璁稿拰寤鸿锛屾垜涔熻皥璋堟垜鐨勪竴浜涚湅娉曘
鐩墠鎴戜篃姝e湪浣跨敤杩欎釜UI搴擄紝鐪熺殑寰堟锛岀湅鍒扮ぞ鍖鸿繕鍗佸垎娲昏穬浠ュ強鍦ㄧН鏋佹帹鍔ㄥ彂灞曪紝鐢ㄧ殑UI搴撳湪钃媰鍙戝睍涓紝鐪熺殑鐢辫》鐨勬劅鍒板紑蹇冦
浣嗗悓鏃朵篃寰堟曚娇鐢ㄨ繃绋嬩腑鐨勭増鏈敱浜庤繕鍦ㄨ凯浠d腑锛屽悗闈㈡兂瑕佽窡鐫鐗堟湰鏇存柊姣旇緝鍥伴毦锛屾瘮濡傛湁浜涗汉鎻愬埌鐨刯query绉婚櫎鐨勯棶棰橈紝杩欐牱鍙兘瑕佹绱㈡洿鏀瑰緢澶氱浉鍏崇殑浠g爜銆傚彟澶栵紝褰撴垜浣跨敤UI搴撶殑鏃跺欙紝骞朵笉鏄嬁鏉ュ嵆鐢ㄧ殑锛屾湁涓浜涘湪涓婚鍖栦腑鍙橀噺鍊肩殑淇敼锛岀敋鑷虫湁浜涙椂鍊欏洜涓轰笟鍔¤姹傜殑涓嶅悓锛屼細鍘绘敼涓浜涚粍浠舵簮浠g爜鐨勮剼鏈昏緫鍜屾牱寮忥紝濡傛灉鎴戠洿鎺ユ洿鏂帮紝閭d箞杩欎簺淇敼灏遍兘浼氫涪澶变簡锛屾垨鑰呭湪鏇存柊鐨勭増鏈毦浠ユ壘鍒拌淇敼鐨勪綅缃簡锛屽鏋滅増鏈洿鏂拌兘澶熻冭檻鍒拌繖浜涘氨澶己浜

@brunotourinho
Copy link

@brunotourinho brunotourinho commented Feb 8, 2021

Google translate to the rescue 馃槄

Sorry I can't express it in English. This question seems to be expressing expectations and suggestions for v3. I will also talk about some of my views.
I am currently using this UI library, which is really great. I am really happy to see that the community is still very active and actively promoting development. The UI library I use is booming.
But at the same time, I am afraid that the version in use is still iterating, and it is difficult to follow the version update. For example, some people mentioned the problem of jquery removal, which may have to retrieve and change many related codes. In addition, when I use the UI library, it is not ready to use. There are some changes to the variable values 鈥嬧媔n the theme, and sometimes the script logic and style of some component source codes are changed due to different business requirements. , If I update directly, then these changes will be lost, or it is difficult to find the location to be modified in the updated version, it would be too strong if the version update can take these into account

@excitedbox
Copy link

@excitedbox excitedbox commented Feb 9, 2021

yes this is a very important thing to keep in mind. I have been looking for a list of all the tags for about an hour now so that they can be pieced together dynamically/programmatically.

Even just that would be nice. 2 arrays that contain all the CSS attributes and name spaces/properties. I guess if the theme builder code is made available in V3 that could be usable in projects that need to dynamically add elements.

@evangow
Copy link

@evangow evangow commented Feb 26, 2021

Given this issue was opened over 2 years ago now, I'm wondering if v3 is still happening or not. Total re-writes as outlined are incredibly challenging, so I know there's a ton of work that would have to go into something like this.

@hammy2899 or @lubber-de?

@lubber-de
Copy link
Member

@lubber-de lubber-de commented Feb 26, 2021

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks for reading 馃檪

@Jogai
Copy link

@Jogai Jogai commented Feb 27, 2021

Regarding unmaintained dependencies; If Fomantic would take the burden anyway it might be better to have it as a seperate utility package/project. Its use would extend beyond fomantic that way and in turn gets more used, which means more developer interest, hopefully sparking more contributions, i.e. less bugfixing for the fomantic team to do.

Even better if such a package already exists somewhere else..

@evangow
Copy link

@evangow evangow commented Feb 28, 2021

Thanks for the thoughtful response @lubber-de!

I don't currently use this repo, so take this comment with a grain of salt (or a giant handful!).

I currently rely on SUIR, and I'm really hoping that they transition to using Fomantic as the base CSS since so many awesome new features have been introduced here, and it seems they may go that direction: Semantic-Org/Semantic-UI-React#3397 (comment)

You would have a better idea than me, but it may make sense to pin some of the other issues (or a tracking list), which people can contribute to and can help this library move incrementally toward some of what is envisioned in the v3 roadmap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
FUI v3
  
Proposal
Linked pull requests

Successfully merging a pull request may close this issue.

None yet