Fomantic-ui: The discussion of jQuery & it's relevance to v3

[hammy2899]

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. :thinking:
We have to discuss this further. There are always pros and cons. That`s why we will hear your voice :slightly_smiling_face:

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

@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! :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:

... (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 🙂

[lucasdcrk]

I agree with @douglasg14b, jquery should be removed. I don't see any drawbacks for jQuery users if there is some kind of polyfill to make it backward compatible. But it will be a significant advantage for those who don't want jQuery or want compatibility with Vue, Angular, ...
So IMO removing jQuery is the way to go as a lot of people complain of SUI requiring jQuery wich led to a vanillajs community fork.

[lubber-de]

@lucasdcrk The SUI VanillaJS Fork replaced jquery by native functions. You will get rid of the jquery library, but this way it is still manipulating the DOM directly in the framework. This still interferes the usage of other popular libaries like vue or react which use virtualdom. :thinking:

[lucasdcrk]

Yeah IK but the point was to show that people will be interested if FUI becomes jQueryless

[douglasg14b]

I think it rolls back around to the potential to use a web-components base in future versions. Which IMHO should be JQueryless.

[batata004]

I dont know it this is the right place to discuss what I am gonna say but I think jquery is not at all a problem with Fomantic. It works fine, is well optimized and in 99% of applications, the user will have to use jquery anyway or any other form of "advanced" DOM manipulation. It will be very rare for a use case where Fomantic will be used in a website/app without jquery or similar library.

I think the community should focus its attention to gulp build, to make building Fomantic UI more powerful. There are several optimizations that Fomantic UI could allow users to apply in the semantic.josn file. Nowadays, Fomantic UI size is huge (both CSS and JS files). I am not even talking about having to demand browsers to PARSE those files.

If you use a full blown minified CSS file provided by Fomantic UI you will already get a hit of 20 points on Google Pagespeed Insights - even if you dont do anything else (import any other libraries, add any DOM elements). Google compalins that parsing Fomantic UI files takes too long.

I totally agree. Even after using gulp build to remove many components I still get a hit of 13 on Google Pagespeed. Many many other things could be optimized still. Users could be able to choose only specific social buttons, choose transitions types... there about 1000 lines (unminified) of CSS just to support dozens of transitions. At the end, users might just use scale but would still have to use 1000 lines cause gulp build does not let users set the transisitons they would like to use. Same with colors, button sizes...

This library is very powerful, it has lots of functionality and it's becoming to be it's greatest evil. With too much functionality/flexibility the end code gets too big and the developers should be able to precisely "pin point" what they want to use and nothing else.

jQuery by itself does not introduce too much load, Fomantic UI itself is what is causing this framework to become so "heavy" - not only in size (KB) but also in performance cause everytime a CSS file is loaded to the browser it has to parse, compile... and it takes too much time, specially on mobile.

Jquery is widelly used on many websites, so when a user hits a website that requires jquery and it is loaded from a CDN, it's very likely the browser will have already a copy of jquery not only in cache, but already compiled, ready to use!

[hammy2899]

@batata004

99% of applications, the user will have to use jquery anyway or any other form of "advanced" DOM manipulation.

I think this is wrong since a lot of people are starting to use frameworks like React, Vue etc which don't have jQuery and can't support jQuery since jQuery breaks the functionality of them libraries.

There are several optimizations that Fomantic UI could allow users to apply in the semantic.josn file.

We will be changing a lot about the build process in v3 which should allow a lot of customization to your build.

Jquery is widelly used on many websites, so when a user hits a website that requires jquery and it is loaded from a CDN, it's very likely the browser will have already a copy of jquery not only in cache, but already compiled, ready to use!

This is completely wrong, this is not how browser caching works. If a user goes to a website which has jQuery the browser has to treat that file just like any other file and load it and cache it for that website. Browsers can't simply treat files the same across websites because its the same library its just like git services like GitHub they can't save on space by only storing 1 version of the jQuery source code for all repos because what if your jQuery file has been modified to add your own functionality then it wouldn't be stored. Also that would be a huge security risk.

[batata004]

@hammy2899

This is completely wrong, this is not how browser caching works. If a user goes to a website which has jQuery the browser has to treat that file just like any other file and load it and cache it for that website. Browsers can't simply treat files the same across websites because its the same library its just like git services like GitHub they can't save on space by only storing 1 version of the jQuery source code for all repos because what if your jQuery file has been modified to add your own functionality then it wouldn't be stored. Also that would be a huge security risk.

You are the wrong here, respectfully. If the New York Times uses jQuery loaded from https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.js and my website also uses jQuery loaded from the same CDN, the browser:

1) wont need to request that file again (at most it may check if the file is staled on cache);
2) wont need to download the file again;
3) wont need to parse the file again;
4) wont need to do thousand of checks regarding code security, errors, exceptions...;
5) won't need to compile the file again;

The browser will just get the compiled version from cache and execute it.

Regarding React being incompatible with jQuery I think that making Fomantic UI not dependent of jquery will require lots of changes, tests... this will take forever. In the meantime, I am pretty sure Semantic UI (the "official" outdated) will surelly become updated, with added features, better gulp build while Fomantic UI will still be testing/replying tons of bug reports on GIT.

I think if there were unlimited man power working in this Fomantic UI project, sure you are right! We should get Fomantic UI independent of any other framework. But that's not the case, I see just a few (and the same) brave souls always answering issues reports, question reports, bug reports... any time I open some discussion good foks like @lubber-de and @hammy2899 are the only ones willing to help among other few guys. This demonstrates clearly that this framework is very limited in "man power" so I think it should focus efforts into things fixing things, not implementing new things while old things are still due to a fix.

[hammy2899]

@batata004 Sorry I should have been more clear about explained the caching thing a bit better. I was trying to make a point about caching and loading FUI not jQuery itself, I was just using jQuery as the example since that is what you where referencing.

The core FUI team is 4 people so your right we don't have lots of man power and yes there is only a few people replying to issues etc. but you have to remember all 4 of us have jobs and a life and we work on FUI in our free time. There is also lots more going on then what an outsider can see from GitHub issues.

I just want to say we are open to anyone who wants to join the contributing team and help out the only "requirements" we ask is you have a decent understanding of the codebase and the SUI/FUI project.

That being said we have done prototypes and me personally I have done lots of research and continue to do so every day with regards to v3 and from my research and prototypes the team has done the rewrite wouldn't take as long as I think you would expect.

Also the v3 rewrite isn't something which will just be a months work this is going to take a while. I opened the initial issue for v3 about 1.5 months ago and we are nowhere near finishing the planning and proposal phase.

[batata004]

@hammy2899 alright now I got what you meant. I would really be glad to participate and contribute coding but my programming skills are very limited. I could become a beta tester of your code, I work for a company that runs thousands of websites and we can easily scale up the tests and check errors and very specific weird cases where bug/issues are happening.

I know it's not gonna be in a matter of months that v3 will be out but I think, in my respectful opinion, that for now devs should focus on making gulp build better, outputing a cleaner/more optimized code.

I am really greatful for your attention into this v3, no matter what, I know for sure I will be able to use jquery with it (wheter it comes by default or not) and it will be a really great framework! Just remember, when possible, to keep 2.x version updated cause there is no hope from semantic ui getting updates any time soon

[hammy2899]

@batata004 If you want to help out by testing new release that would be awesome. We can talk further about this if you want.

As of working on the build process it is a larger task then it looks and would possibly be too large of a breaking change which is why we are doing a lot of research into the topic for v3 because we want to get it right this time and want to allow the ability for us the change the process if need be without breaking the user implementation.

As for updating v2 we are continue to do so as we develop v3 (I am currently working on 2.7.2 right now).

[batata004]

@hammy2899 sure I am all in into testing! We have websites running almost all version of jquery and many other popular libraries, outdated websites, newer... I would be glad to test. :)

I thought the build was something easier to do, I was not aware of how much work it demands! Thanks for keep updating 2.x you guys are awesome!!

[hammy2899]

@batata004 Join the FUI discord so we can talk further so this issue doesn't get off-topic.
https://discord.gg/YChxjJ3

[Bradley-H]

Take my opinion as you may, currently Semantic has a gigantic file size, (i think the .js is like 700kb alone) which is I think unnecessary any way you look at. especially if you value performance. Even if you are heavily reliant on jQuery, I think someone can easily make a snippet of Semantic 3 js as a quality of life improvement for the framework.

[thiscantbeserious]

@Bradley-H

Take my opinion as you may, currently Semantic has a gigantic file size, (i think the .js is like 700kb alone) which is I think unnecessary any way you look at. especially if you value performance

"Gigantic file size" ... in what terms?

You can run the whole thing from an ESP8266 if its just about the code ... maybe even combined with LoRa in your garden for whatever freaking reasons you'd like to to that (but hey!).

If we'd be speaking about a thousand smaller files that get loaded at once with HTTP/1 then we could talk but these overoptimizations in terms of file size with code are most of the time really going over board and are "the wrong ship to tackle in my opinion". Compression, concatenation, minification ... especially for the assets itself - that stuff is more worthwile than cutting your code in half for the sake a few KBs.

Getting rid of jQuery should reduce the waste quite a bit - and I agree that jQuery has long since become an burden. Especially the jQuery UI components itself with all their technical debts.

You can do the most of it with plain JS nowadays. Its just a matter of time and certainly not something you'll just do over the weekend (unless 75% of stuff breaks) - something that should be sufficiently unit-tested and trendemously verified. More like weeks to months of work and not something "you easily do as a QoL improvement by clicking FORK on GH".

[batata004]

I cant believe you guys are still talking about jquery... JQUERY IS NOT THE PROBLEM. Semantic UI itself is THE problem.

Only the TRANSITION module of Semantic consumes more than DOUBLE than JQUERY! I mean: only one of the dozens modules from Semantic!

@thiscantbeserious you cant be serious when you are talking about esp8266 boards. Those are meant for other purposes. NO ONE WILL RUN a legit website on it.

If you run a legit business that really needs an optimized website that ranks well on google and open fast, you will have A LOT OF PROBLEMS trying to optimized FOMANTIC on yourself. Even using GULP you are very limited, your "compiled" files still look huge.

With ALL DUE RESPECT, I think that people behind fomantic/semantic has no idea how important is to many business having their website with a score over 95 on Google PageSpeed. I think people behind fomantic have no idea that on most countries of South America, India... people use a sh#t internet, on sh#t outdated devices... IT'S A MUST for business targeting those regions to have a fast website.

I cant believe we are still discussing JQUERY... it's more than clear that JQUERY IS NOT the problem here guys... I know I am wrong, but I have reasons to believe that devs behind semantic/fomantic dont use it on a daily basis. I cant believe you guys use semantic/fomantic on your business websites or on your customers's websites. If you did, you would know what I am talking about.

I dont mean to offend anyone, I am criticizing the way this discussion of jquery is taking again... WE SHOULD ATTACK THE PROBLEM, not the solution. For most devs JQUERY IS STILL the solution - and is a GREAT SOLUTION!

Business who target SOUTH AMERICA countries, INDIA... have to rely HEAVILY on JQUERY cause their audience still uses IE6 and IE7!!!! Android KITKAT or even older... Those devices/browsers dont have good selectors and cross browser code to effectively travel across the DOM. JQUERY wraps that all and make our lives easier. YOU MAY HAVE FORGOTTEN BUT I STILL DEAL WITH CUSTOMERS USING IE7. I THINK YOU GUYS should take a look back and remember the days you had to deal with IE. I think you all forgot the jokes and memes about IE 7. I am not even talking about IE6!!

If devs of Semantic/FOMANTIC want to target people using flagship phones on 5G networks... go ahead then, I will leave this ship and look for other libraries cause 99% of my audience/customers are still on 3G/EDGE networks with phones that are not even sold anymore on US.

[thiscantbeserious]

3G

Drama very much? I did not do the math but as a said the Code should be least issue here - the assets itself hold more optimization possibilities (assets as in images and whitespace).

I'm not living in africa and using 3G most of the time for power saving as well and still don't see that this is an issue and should be related to 5G like at all.

We're not talking about multiple MBs of data here on each request.

Heck on 7,2 Mbits that 700 KB will still only take less then a single second to load.

Moreover it will be cached afterwards - so you exactly only need to download it once (that is unless people clear their cache, which they'll rarely want if they're on slow connections).

That is if you implemented it correctly and have your server setup correctly. This includes stuff like GZIP compression ... but nothing the library is responsible for, but you as the maintainer of that website/application in itself (!).

The issue with jQuery is the dependency on it and the unessecary overhead it creates - this issue here is related to that alone. The less dependencies you usually have the easier something is to work in correlation to - for example other frameworks and libraries and the less side-effects you usually get.

That's the idea behind it.

Why not fork this, optimize what you deem important and send a pull request?

That's how Open-Source works. Also nobody will be mad if you look elsewhere to.

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

[thiscantbeserious]

YOU MAY HAVE FORGOTTEN BUT I STILL DEAL WITH CUSTOMERS USING IE7

People that support such technologies are part of the problem and not the solution*.

Its not (!) how you solve problems, its how you introduce them. Nobody forces you to change or update as well (as in stick with the version that ditches jQuery, when/if its decided)!

Let me come back to your big old behemot:

https://support.google.com/analytics/answer/3541880?hl=en

Even Google isn't supporting all versions of IE anymore - by that I mean even IE11. Edge or nothing.

You really argue yourself upside down across the neck.

People around the world can and do use Linux - it's free and can be used everywhere (provided they know how to, I know that getting the initial Distro can be a pain in the ass, so that's not always an option - but even there you can install Firefox).

Also people can simply use a proper Browser even in their jack shit old Android-Versions back to Jelly Bean:

https://support.mozilla.org/en-US/kb/will-firefox-work-my-mobile-device

You are indeed stupid

Have a nice day too.

@hammy2899 sorry for the Off-Topic ...

I'll stop here I swear no matter the insults I'm thrown at afterwards :dagger:

---

*you could for example use your endless wisdom explaining them why it's a bad idea to stay on IE. I mean instead of insulting random people on GitHub. ;)

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

[hammy2899]

I completely agree with all the points @thiscantbeserious and @douglasg14b and for what its worth no matter what people say jQuery is getting removed in v3 and thats the end of this discussion.

I am locking this issue because its becoming way to hostile.

---

@batata004 Please read our code of conduct because some of the things you said our way over the line.

[hammy2899]

Closing because the decision towards jQuery has been made so this issue no-longer has any relevance.