The discussion of jQuery & it's relevance to v3

This is a discussion about jQuery and why it should/shouldn’t stay in FUI for v3. This thread was started in The future of FUI in 2019 and v3.0

Below is a complete thread of all current comments

---

@donaggio (link):

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 (link):

@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 (link):

@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 (link):

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 (link):

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

@hammy2899 (link):

@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 (link):

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

… (comments in between)

@batata004 (link):

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 (link):

@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 (link):

@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 (link):

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

… (comments in between)

@lubber-de (link):

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

@hammy2899 (link):

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

… (comments in between)

@labby (link):

@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 (link):

@labby

please also respect mine.

I definately do! 🙂 Sorry, if my comment got mislead! 🤝 We want to hear your opinion, that’s why this thread was created

And i love, you guys are already testing the next version! 👍

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

Of course! 😆

… (comments in between)

@batata004 (link):

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 (link):

@batata004 this has been addresses many times in this discussion. Who says that FUI is going to increase in size?

FYI calendar is already implemented in Fomantic UI: https://fomantic-ui.com/modules/calendar.html

@batata004 (link):

@ColinFrick FUI will not be bigger in size when it removed jquery dependency? So how will you do all the “selector” stuff without adding new code? “queryselectorall” will not do all the heavy lift on its own.

PS: thanks for pointing the calendar, I was not aware FUI had it!!! GREAT!

@etshy (link):

@batata004 you can still stick to v2.x.x of fomantic to have jQuery, no ?

And when v3.x.x will be released + a jQuery wrapper, you’ll get all you want.

I can’t understand your worries here, when semantic ui is clearly too slow to be interesting to use at the moment.

@batata004 (link):

@etshy so let’s wait to find out. I agree with your last statement. However, I better stick with SUI (despite slow updates) to avoid changes/troubleshooting on thousand of websites when FUI decide breaking backwards compatibility.

@hammy2899 (link):

@batata004 I think you have misunderstood something while reading. In this comment and the following replies we mention about adding a “pollyfill”/adapter from v2 to v3, this will mean all your websites will work exactly as expected with no code change even if we remove jQuery.

Your point about FUI increasing in size. The library won’t increase if we remove jQuery since we will be removing jQuery it will be reducing the size because we will be using native functions.

@Atulin (link):

Also, the current code is not exactly up to modern standards in all places. Removal of jQ would also be a good opportunity to go over the entirety of the code, finding unoptimized pieces and optimizing them.

Far as I can tell, the removal of jQ will most probably result in decreased size and increased performance.

@batata004 (link):

@Atulin @hammy2899 time will tell if the “jquery less” version will be smaller. Respectfully disagree, you cant make a code smaller adding news features (like removing jquery). Somehow you’re gonna have to code your “selector engine”.

I dont want to keep this jquery discussion further, I dont want to bother you guys here with this jquery thing. It’s a bold move and clearly it’s gonna happen and, despite disagreeing, I know for sure you are doing this for the better 😃 Keep on good job!

… (comments in between)

@douglasg14b (link):

@batata004

My $0.02 on JQuery. Before I begin I’ll say that I still use JQuery on many projects that don’t use a framework like Vue, React, or Angular. It provides plenty of functionality that vanilla JS still doesn’t.

It’s not used everywhere (contrary to claims, most of it’s usage are VERY old versions), has been effectively replaced by many vanilla and framework alternatives. It’s clunky, messy, and will drag down the framework in the future where JQuery will no longer exist in mainstream applications. There is no reason to have a death-grip on the past that is JQuery. Your arguments that the time can be better spent else-wear is a false economy, as it will cost much more time in the future to remove JQuery Which WILL happen eventually. And cost an indescribable amount of dev hours for users of the frameworks who are held back by the JQuery dependence, and the bugs/issues/slow development inherent to sticking with it’s patterns. When we could be making an agnostic framework that works out of the box for SPA frameworks. You are potentially hamstringing the future of the project by forcefully keeping a dependency that has been fading from modern use…

Other UI frameworks have already made this leap, and are ploughing forward and leaving Semantic in the dirt to wallow around as part of the “old guard”. Similar to how NLog or Log4Net are nearly considered legacy in the .Net ecosystem for their inability to adopt new ideas and paradigms. Lets not become a legacy framework.

@douglasg14b (link):

On second thought, I think JQuery-related discussion should be in it’s own thread/issue to prevent it muddling up more important conversations about the future of SUI/FUI. Not that the JQuery conversation isn’t important, but it’s divisive, which can be very bad for a discussion meant to be future-facing. Since it shifts the focus into an argument over one item, instead of a discussion about the framework as a whole…

I fell into that trap with my above comment. and contributed to the off-topic mess.

@hammy2899 (link):

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

@douglasg14b (link):

@hammy2899 If so, is there a way to move comments to another issue? Failing that, copy/pasting them as quotes would do if a line can be drawn pushing that conversation over there.

@batata004 (link):

@douglasg14b I agree with most what you said but I was never trying to predict the future. You said that in the future jquery will be “legacy”. Sure. As will “Fomantic/Semantic”. As time passes by, browsers are implementing lots of standards and helping devs to spend less and less time with that “semantic stuff”. I am pretty sure, a few years ahead, it will be much easier to users customize their websites/buttons without relying - or having to choose - a framework. You certainly will be able to use frameworks but they will add more than an overhead than a significant leap. Today, FUI/SUI helps A LOT when building apps/websites. In the years to come, I dont think it will be that much* important. I just want to say that, when jquery is gonna be considered “legacy” I am pretty sure most of what FUI/SUI provide today, will so too. But I understand the reasons why devs usually want to create “indepedent framework” (“jqueryless”, for example) and most of the time I dont agree. But I’ve been wrong much more times on my life than right, so yeap, dont mind my opinion.

I also agree with @@douglasg14b that this jquery discussion shouldnt be part of this thread and I promise I will stop posting about it.

---

Please continue the conversion here 🙂

[douglasg14b]

@batata004

TBF the file size isn’t necessarily the reason that JQuery is problematic… it’s compatability with web frameworks which are becoming a majority stakeholders in web application development. JQuery isn’t necessary to get JS to work on older browsers, there are shims for that.

Past that, a line needs to be drawn, does Fomantic fade off into the past and become a legacy framework, or does it move forward with the rest of the web? Directly supporting long deprecated browsers does not seem to be in the best interest…

Plenty of frameworks that are more feature-complete than Fomantic use web components with similar or smaller file sizes, so that doesn’t seem like that significant of a concern… Especially with tree shaking. This can be done in a a number of ways, such as building for specific frameworks (ie. React & Vue), and just exporting the vanilla components from either.

---

For my current projects, I wanted to use Fomantic, badly. Cause I love the framework, and ahve been using Semantic for ~3-4 years now. But I needed operational efficiency, which is not something I can achieve while trying to crowbar Fomantic to work with Vue and Angular. So I went with frameworks that have feature-complete Vue and Angular builds, like Bootstrap and the variety of material frameworks… I still use Semantic/Fomantic here and there, but it’s on older applications and static sites, not really anything new.

This is going to become a more common story as time goes on.

[batata004]

@thiscantbeserious I couldnt even read your answer after you said "

I’m not living in africa

". I cant believe there are people like this in the community.

Anyway, you lack lots of experience. When I was short answering you, my eyes couldnt afford seeing the “less then a single second”. You are indeed stupid and you dont know what is pagespeed, thinkwithgoogle, google insights… Wasted time here.