y0hami commented 5 years ago

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)

jamessampford commented 5 years ago

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

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

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

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

batata004 commented 5 years ago

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

jamessampford commented 5 years ago

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

mikejf-pr commented 5 years ago

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

bborn commented 5 years ago

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

y0hami commented 5 years ago

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

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

Ray-B commented 5 years ago

In on the survey in the nick of time.

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

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

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

douglasg14b commented 5 years ago

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

y0hami commented 5 years ago

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

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

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

thiscantbeserious commented 5 years ago

@YamiOdymel Yes I agree unit testing UI will be hard and pointless with the amount of work it would take, thats why we want to make a repo with examples of each component in near to all variations so we can check that they look as intended. Looking over all these examples by human eye would be stupid so thats why we are looking into something like percy. Thanks for your info

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

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

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

https://jestjs.io/en/

4val0v commented 5 years ago

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

wdmeest commented 5 years ago

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

y0hami commented 5 years ago

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

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

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

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

Aniel commented 5 years ago

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

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

y0hami commented 5 years ago

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

wdmeest commented 5 years ago

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

GammaGames commented 5 years ago

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

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

y0hami commented 5 years ago

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

YamiOdymel commented 5 years ago

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

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

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

certainlysylvia commented 5 years ago

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

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

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

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

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

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

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

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

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

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

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

Kate out ..

ptejada commented 5 years ago

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

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

goodwin74 commented 5 years ago

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

We have already switched all projects to Fomantic-UI 👍

y0hami commented 5 years ago

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

However thanks for the offer 👍

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

tomByrer commented 5 years ago

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

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

y0hami commented 5 years ago

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

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

0xF6 commented 5 years ago

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

Daniel127 commented 5 years ago

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

271ch commented 5 years ago

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

y0hami commented 5 years ago

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

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

bornemisza commented 4 years ago

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

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

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

y0hami commented 4 years ago

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

batata004 commented 4 years ago

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

y0hami commented 4 years ago

@batata004

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

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

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

bartocc commented 4 years ago

@hammy2899 I believe you meant to mention @batata004

y0hami commented 4 years ago

@bartocc Oh yeah sorry 😄

y0hami commented 4 years ago

Update regarding v3

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

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

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

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

Now for some details on what we will be shipping.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

dutrieux commented 4 years ago

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

bborn commented 4 years ago

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

brunotourinho commented 4 years ago

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

ansarizafar commented 4 years ago

Why not support Svelte?

y0hami commented 4 years ago

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

Polve commented 4 years ago

Great work and roadmap guys.

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

ansarizafar commented 4 years ago

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

y0hami commented 4 years ago

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

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

DepaMarco commented 4 years ago

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

douglasg14b commented 4 years ago

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

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

Polve commented 4 years ago

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

y0hami commented 4 years ago

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

douglasg14b commented 4 years ago

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

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

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

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

donaggio commented 4 years ago

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

fomantic / Fomantic-UI

The future of Fomantic as v3.0 #319

We have a ROADMAP now 🎉

New Documentation Website

New Build Process

Theme Builder & Web Store

Project Structure

ES6 & JS Rewrite

Tests tests tests

Update regarding v3