The future of Fomantic as v3.0

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)

Atulin commented 5 years ago

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 commented 5 years ago

@Atulin While working on https://github.com/fomantic/Fomantic-UI/pull/261, rethinking the themeing logic as well as reducing the amount of variables is definately on the roadmap.

etshy commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@donaggio We could think of some kind of adapter-system where you can choose if DOM manipulation should be done by familiar old jquery function names, internal/native ES6 functions or even a new virtualDOM system like for example https://mithril.js.org/ uses. That would probably still mean to always use wrapper-functions. :thinking: We have to discuss this further. There are always pros and cons. That`s why we will hear your voice :slightly_smiling_face:

y0hami commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

y0hami commented 5 years ago

@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 commented 5 years ago

@hammy2899 Great! That would provide an easy migration path from 2.x to 3.x retaining full compatibility while we switch from the old syntax to the new one.

singhda8 commented 5 years ago

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 commented 5 years ago

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

princeandrew01 commented 5 years ago

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

romaninsh commented 5 years ago

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 commented 5 years ago

I'm also creating an UI Component library, and I'm not gonna lie, but front end with unit testing is harder than learning C language.

You will waste more time on creating unit tests, and once you changed the CSS/Style, you will have to change the unit test too. Everything will be like a chain and you will have more jobs and code to change: xkcd: Automation

My stupid idea to compromise with this issue is to create a test page (with Pug) for each of the components (a little bit like Kitchen Sink of Semantic UI)

with a customized page generator (I made it with Golang in this example), it will generate a component test page with an index list, and I can debug or make sure it looks okay with the human eye (yes, I tested the components on my own, at least it's simple).

If you are trying to test the JavaScript modules... I think it's fine since you are testing with the behaviors of them. But if you want to test the CSS styles... it's might be really- hard.

douglasg14b commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

y0hami commented 5 years ago

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

y0hami commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

Bradley-H commented 5 years ago

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

y0hami commented 5 years ago

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

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

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

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

y0hami commented 5 years ago

We are running a survey for v3 research, if you have 5 minutes to spare to fill it in we would be much appreciated! https://www.surveymonkey.co.uk/r/398M9YJ

aardbol commented 5 years ago

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

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

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

pfcodes commented 5 years ago

Webpack for the build process?

domenkozar commented 5 years ago

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

lkraav commented 5 years ago

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

y0hami commented 5 years ago

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

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

levithomason commented 5 years ago

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

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

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

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

lkraav commented 5 years ago

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

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

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

douglasg14b commented 5 years ago

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

What are your opinions on this?

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

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

ansarizafar commented 5 years ago

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

gaurav- commented 5 years ago

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

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

This is an exciting proposition!

batata004 commented 5 years ago

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

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

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

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

ColinFrick commented 5 years ago

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

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

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

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

labby commented 5 years ago

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

batata004 commented 5 years ago

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

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

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

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

labby commented 5 years ago

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

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

lubber-de commented 5 years ago

@labby

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

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

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

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

y0hami commented 5 years ago

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

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

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

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

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

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

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

y0hami commented 5 years ago

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

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

levithomason commented 5 years ago

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

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

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

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

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

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

labby commented 5 years ago

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

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

lubber-de commented 5 years ago

@labby

please also respect mine.

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

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

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

Of course! :laughing:

labby commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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

fomantic / Fomantic-UI