Eliminate Dependency on jQuery

[martindale]

The dependency on jQuery is largely unnecessary, and this library would be much smaller and even more performant if it were to find more specialized tools to implement the features that jQuery currently provides.

[jlukic]

We're using all the toolkit provided in jQuery. There may be a way to roll with Zepto, but I haven't had a chance to check it out. Most of the stuff is pretty necessary for our project, selector engine, dom insertion, etc.

[sethlivingston]

I wish you guys would reconsider opening this. jQuery is really slow, especially on smaller devices, and there is very little that jQuery does today that you couldn't do in a much, much smaller library. I encourage you to learn more about jQuery's diminished position in this industry. I would love to use Semantic-UI, but this is a show-stopper.

[FoxxMD]

:+1:

[ftaljaard]

would love to use Semantic-UI, but this is a show-stopper. Same here jQuery is a no go for me

[fgarcia]

I would love a good overview of the parts depending on jQuery. Semantic UI is a clear winner because of the amount of elements, but depending on jQuery sounds scary for users of libraries based on a virtual DOM such as React.

If I want to use Semantic UI without jQuery, which components will stop working?

I am ok with loading jQuery, but it seems more of an unnecessary burden every year that goes by.

[dobrych]

@fgarcia i've found a way to handle it in React by just applying conditioned css classes using React states, this enables widgets like menus, drop-downs, etc, but not animation jQuery is definitely a burden for such a simple tasks like class manipulation and animation

[FoxxMD]

Also can't do validation of forms without jquery.

[tubia]

I really don't understand why to close this issue.
As many people here have pointed out, jquery is unnecessary burden.
I'm writing a small component for a legacy web application which will break if I use jquery. I implemented some semantic-UI elements but stopped when I found that the JS for an element like tabs requires jquery.
Well, I'll try to refactor a bit of the tabs.js or maybe I'll write a little tab switch on my own.
I still remain with a great question mark: do you use jquery only to select DOM elements and to make a few AJAX calls? Really?

[fgarcia]

I don't think removing jQuery is an easy task or even practical considering the large amount of widgets there are in Semantic-UI but it would be great having two versions of Semantic-UI, something like the "base" version and then the "extras" requiring jQuery.

[nicbarker]

+1 for removal of the jQuery dependency. The extra weight makes it just that much harder for someone to justify dropping semantic into a production project, especially if it's only for one or two components.

[sunnysingh]

jQuery dependency is a show-stopper for me as well. I understand the amount of time it would take to transition the project over to pure JS or a smaller library (see Bliss.js), but in the end it would attract a ton of developers. All the use cases for jQuery are honestly overshadowed by browser support for document.querySelectorAll() and fetch() although some polyfilling would be necessary. Hope this issue sees a re-consideration at least for the future of Semantic UI.

[amir-s]

I came across semantic-ui and was quite impressed by it, until I found that I need jQuery to get it to work. Specially if one wants to use semantic-ui with angular or react.

I would also suggest to drop jQuery. I'd be happy to help with that.

[djyde]

I used CommonJS so there was no global jQuery instance. But...

[hiteshjoshi]

+1

[brickyang]

This topic is closed on 22 Oct 2014. Today is 20 Mar 2016. The JavaScript and browser world has a huge processing. It's apparently jQuery is not necessary nowadays. I understand it's not a easy task to remove all jQuery dependency, but I think it's the right way.

I think the advice of two versions from @fgarcia is a good idea.

[bigzhu]

+1 Jquery is too big in the mobile, and semantic-ui had some css bug in some mobile browser like wechat x5 browser. Need do this work as soon as possible

[jfarlow]

Semantic UI's ember module doesn't work with the new Ember Fastboot because of its jQuery dependency. It would be great to continue using the framework while gaining the benefits of fastboot.

[controversial]

Please reopen this. As everybody above has said, jQuery adds a lot of unnecessary weight to this. I lie this library over Foundation and Bootstrap, but I don't want to add jQuery to my project just for Semantic UI

[avalanche1]

I reopen this since so many people have asked for this. And since Jack expressed his opinion 1.5 years ago, things might have changed since then. At least we should keep this open as a feature request.

[controversial]

Yay!

[jlukic]

Seems fair to leave it open, although this would be nothing short of a rewrite of all js components.

[controversial]

@jlukic How many of the components would require rewrite? How many are jQuery based, in short? I'd be happy to take a look at a few, but many are likely over my head.

[martindale]

I'm sure there are plenty of people who will want to take this on; perhaps we can start a milestone to track issues against?

[controversial]

@martindale I agree. I don't have the skills to do much of this, but I'd love to help in some way. I can probably do some of the simpler stuff.

[hiteshjoshi]

Guys, If someone can create a sort of roadmap and a product architecture and a tiny document guide of how the main developer want us to build the components, we can start coding it. Got the skills. Can devote time too as I use semantic for majority of my projects.

[controversial]

Absolutely. I can devote time because I'm a high school student without a full time job.

[sethlivingston]

@hiteshjoshi I can help, too.

[controversial]

@jlukic @avalanche1 We have 3 people to work on this now. Could a tentative guide be put together? Including things like how components should be written, and what the minimum browser support will need to be?

[jlukic]

We're talking about rewriting 22,000 lines of javascript code to exact feature parity without jQuery.

I understand you guys are willing to help, but i think this isnt something that can just be hammered out in a weekend.

[controversial]

All of those 22,000 are heavily jQuery dependent? Yikes. On Sun, May 1, 2016 at 2:40 PM Jack Lukic notifications@github.com wrote:

We're talking about rewriting 22,000 lines of javascript code to exact feature parity.

I understand you guys are willing to help, but i think this isnt something that can just be hammered out in a weekend.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Semantic-Org/Semantic-UI/issues/1175#issuecomment-216063154

[jlukic]

I don't really get the vitriol here. There's nothing inherently wrong with jQuery... its just a wrapper around obtuse browser APIs.

Every component is distributed as separate standalone repos. Unless we write our own wrapper around the DOM we're going to have to rely on the same utility functions in each independently distributed component, which would mean creating our own proprietary addClass, removeClass find etc that will add additional weight and be somewhat re-inventing the wheel.

[jfarlow]

As @fgarcia mentioned, would it be possible to have more of a separate version than a rewrite - a 'basic' and a 'full' version? A basic version being more than just css, but missing some of the features in a full-fledged animated, behavioral component set? Especially when integrating Semantic UI with other frameworks such as React or Ember, much of the heavy lifting done by the components can easily (and should) be done in the framework rather than by Semantic UI (tabs, form validation, etc.). And in the case of Ember, their new FastBoot mechanism is incompatible much of how jQuery is being used - and so makes incompatible the entire framework even when tabs & validation aren't being used.

Or is there just a fundamental incompatibility between a feature-rich component framework and a larger javascript framework like Ember?

[controversial]

@jfarlow I really like that idea.

@jlukic I guess I feel like jQuery is a fairly heavy library, and it's also not really necessary to have as a requirement. Most of its functions only save ~1-3 lines over the vanilla JS alternatives. My situation is that I'm trying to completely redo the UI for a project. I want to use Semantic UI, but I feel that in 2016 with the state of modern browsers, jQuery is largely unnecessary, and I'd rather not have to include it in my project if it's only being used by Semantic.

That's just my personal opinion, but I think that dropping the requirement would make Semantic UI a better project, make it easier to get started with as well as faster (both in loading and performance).

[avalanche1]

We could start by creating a list of all jquery functions SUI uses on the left and their modern alternatives on the right. Then we can determine how heavy the task really is.

[controversial]

@avalanche1 Sounds good to me.

[avalanche1]

Well, then - let it be task numero uno. Let our volunteers do it and in case we have efficient teamwork we'll see if we can push it further. tasklist here - https://github.com/Semantic-Org/Semantic-UI/issues/3981

[amir-s]

I'm really happy that the issue got reopened. Count on me for any helps as well.

[IonutBajescu]

I know that a lot of people support the idea of removing jquery but have we discussed the downsides of such a change?

A few I can think of right now:

1. Quite a number of projects already have jquery included in their source code, while bundling a jquery alternative in semantic will help the react/angular projects save some space, it'll do the exact opposite to the ones that already use jquery.
2. jQuery when used from a public CDN might be cached on the users' browsers, a not-so-popular alternative will not.
3. Correct me if I'm wrong, but semantic-ui doesn't have an extensive testing suite. We're looking at introducing new bugs into the source code and not even knowing it.

[controversial]

@IonutBajescu:

1. I disagre, many projects have neither jQuery or any alternative. How does this hurt jQuery users? I think that the possibility of having two separate versions is being most seriously discussed.
2. jQuery is still an unnecessary requirement, even though many machines cache it
3. That's kind of irrelevant. The fact that there is no test suite shouldn't be an excuse for not making changes that will make the project more relevant and useful for the future of the web.

[jlukic]

I've run into this same issue with other integrations, like React, and Angular. It isnt feasible to maintain two codebases, and it isnt feasible to recreate SUI feature-set at parity from scratch as a separate codebase.

Even if one was to do that it'd probably take a lot of time and effort to complete. (I'd honestly estimate something like 3 months of work with 9 months of bug testing before matching feature-set.)

SUI is a mature project, and many of these components started being fleshed out around 4 years ago. Most of the hard to find issues didnt emerge until 3000 or so GitHub issues later. I don't think you can throw out the baby with the bathwater here.

[controversial]

I guess. We don't have to start from scratch, though, we can start with the React project.

[levithomason]

At TechnologyAdvice we are using https://github.com/TechnologyAdvice/stardust in production. We have 6 humans and 2 robots working on it so far. I spend the majority of my day job on Stardust.

I am rewriting the modules without jQuery. We first tried to keep SUI DOM manipulations in sync with React state through each of the library's lifecycle methods, in the end, this just was not realistic.

I've rewritten the Dropdown with selection, search, and complete keyboard navigation. You can try it out here. I will continue to move forward with all other modules as well. If any one is interested in assisting, let me know.

[slurmulon]

More than happy to contribute towards this effort as well. I am certainly busy, but we are experiencing endless annoyances with using SUI with Angular 1.5 + Webpack (NG6 seed), mostly due to the fact that SUI isn't properly configured for NPM and it doesn't adhere to CommonJS.

[levithomason]

@slurmulon EDIT sorry, completely ignored the Angular 1.5 part of your comment. I should take a break!

[vinicius73]

Consider VueJS, extremely simple and easy.

[ivosabev]

+1 for dropping jQuery. I am using React and jQuery is a no-go.

[levithomason]

@ivosabev you can checkout Stardust for a React implementation of Semantic UI. We're using it in production while we round out the component APIs. We are mid way through removing jQuery as well, see https://github.com/Semantic-Org/Semantic-UI/issues/1175#issuecomment-216922303 above.

Keep in mind, all forms of DOM manipulation are trouble for React no matter the tool or method used. Only DOM manipulation performed by React through it's own virtual DOM to real DOM diffing and patch update algorithm is safe. While I agree that removing jQuery may make SUI a cleaner library, there will be virtually no benefit to React implementations. Since, in React land, it will always make more sense to throw away all direct DOM manipulation and reimplement it using React's virtual DOM.

This is precisely what we're doing with Stardust.

[jlukic]

@levithomason If you would like to publish stardust as an official react integration in our semantic-org repo, I would be interested in helping with that

[levithomason]

What kind of time do you have available at the moment? It is something I would consider.

[jlukic]

I dont have time to write react integrations, but I can provide support in managing an official integration.