Semantic-ui: 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 [email protected] 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.

[levithomason]

Got it. How about a bullet list of what you're proposing and what we'd gain from the move? I'll mull it over and run it by the team. I'd much rather collaborate.

[jlukic]

We're running similar integrations for Ember and Meteor. Generally adding your project as an official integration would provide higher visibility for your work.

[levithomason]

Sounds good, let me think this through and talk with some folks on Monday. Appreciate you reaching out.

[Ryuno-Ki]

In some countries, Monday is Pentecost - a Christian holiday. I regret, you have to go to work then, @levithomason :-(

[levithomason]

It's crazy. I write apps and tools literally every day and night. It's a labor of love. Somehow, a large slice of my passion is called a job. Do what you love and you'll never _have_ to do it ;)

We should try to keep this thread focused on jQuery, though. Appreciate your concern for me.

[levithomason]

@jlukic I've thought this through and ran some things by the team. It just makes sense, so let's do it. There are some things to work out to make a full transition.

I've started https://github.com/TechnologyAdvice/stardust/issues/243 as a place where we can work these things out. I'll move all future chat about the migration there. Would love your input.

[sethlivingston]

This is great news!

On Mon, May 16, 2016 at 5:35 PM, Levi Thomason [email protected]
wrote:

@jlukic https://github.com/jlukic I've thought this through and ran
some things by the team. It just makes sense, so let's do it. There are
some things to work out to make a full transition.

I've started TechnologyAdvice/stardust#243
https://github.com/TechnologyAdvice/stardust/issues/243 as a place
where we can work these things out. I'll move all future chat about the
migration there. Would love your input.

—
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-219568811

[jlukic]

I'm quite plelased about this, just need to make sure licensing remains MIT for all works published under Semantic-Org

[levithomason]

MIT it is.

[drcmda]

Sometimes i wish Jquery would just disappear. It keeps so many great projects from moving on. I wouldn't let a monolith inside a modular project if someone forced me, or sprinkle $(...) expressions over clean MV code.

if semanticUI would use lodash, which is modular, no problem at all, _but jQuery is a no-go and completely uncalled for_.

Just a neutral vanilla UI lib that can be used anywhere, in React, Vue, Angular and so on, without making them preferences or dependencies. Why is that so hard to get. )-:

[controversial]

@drcmda _always_ I wish jQuery would disappear :P

[levithomason]

Just a neutral vanilla UI lib that can be used anywhere, React....

Keep in mind, no matter what your method of manipulating the DOM (jQuery, DOM API, Zepto, etc.) it is not compatible with React. React uses a Virtual DOM, a complete representation of the DOM in JS. It then renders _one way_ from JS to the DOM. You never read from the DOM.

Because of this, it must keep the Virtual DOM and real DOM in sync. If you touch the DOM in any way, you can blow up your React app. It will yell at you and let you know as well.

So, while jQuery is bloated for many tasks, under the hood it is calling the same vanilla DOM APIs you would have to call yourself. Which are the same DOM APIs the rest of the world has to call. All of which are no nos in React land.

It has been decided that Stardust will become the official implementation of SUI for React. Check it out.

[drcmda]

@levithomason but that is kind of Reacts own shortcoming. Vue for instance can use the dom, without any disadvantage. It would be nice to have at least one quality UI components system that doesn't rely on old monoliths or coaxes you into a specific MV framework.

Stardust still looks great. All the best for it!

[levithomason]

I'd call it an advantage rather than a short coming given the ridiculous performance it brings. Though, I still agree with your points. Thanks for the wishes!

[controversial]

@levithomason Stardust just reached 1000 commits, in case you didn't notice :tada:

[levithomason]

Ha, I did not! 🎉 Awesome.

[cortopy]

jQuery has its uses but with React and Angular 2, there should be more options than assuming the web is like it was 5 years ago where jquery was taken for granted. There are projects where you just can't use jQuery.

I'm not sure if removing it entirely is feasible, but the guys at foundation make it clear in their docs which elements require jquery and which don't. Currently I mix & match from different sources. I'm finding it difficult to do with semantic-ui

[levithomason]

@cortopy Per https://github.com/Semantic-Org/Semantic-UI/issues/1175#issuecomment-219568811 above, Semantic UI now has an official React port, Stardust. This repo will soon migrate to the official Semantic-Org and be renamed to Semantic-UI-React. The docs will live at react.semantic-ui.com. You can find the current docs here.

We started out including jQuery. We've now rewritten everything except forms without jQuery, you can see our progress here.

Though we're racing toward v1 component APIs and removing jQuery, TechnologyAdvice is using Stardust in production. This means there is a team working on it every day. We're moving very fast.

I'd love for you to try it out, give your input, and collaborate with us.

[cortopy]

@levithomason Unfortunately I use Angular 2, not React. I've looked at the Integrations page in the docs, and this seems like a remote option now.

I'd be happy to help with angular2 components though!!

[Enelar]

I think that jQuery is OK.
Since semantic itself weight more than 1MB (uncompressed), next 200KB is not making weather.

[controversial]

@Enelar I don't have anything against jQuery, just that it's 2016, and jQuery is becoming less and less useful. Many people don't _want_ to use jQuery in their projects, and for a project like Semantic UI to have it as a hard dependency isn't something I'm a big fan of.

[brickyang]

@Enelar So you called 20% increases of size is "OK". Not to mention that you don't need to require all "more than 1MB" Semantic files into your project.

[Enelar]

@brickyang this is wrong. I get 265+184=449KB with

  'sticky',
  'segment',
  //'icon',
  'site',
  'container',
  'grid',
  'header',
  'label',
  'reset',
  'image',
  'button',
  'card',

I had to abadon modal and dimmer, i am using vanilla instead. Thanks god i disabled icons. Semantic bloating faster than 20% each half-year. Eliminating jQuery won't stop that process.

In compressed: 23.9+64.6+84.3=172.8KB, so i get your point too. Returning your coin: it don't require whole jQuery to run. Bake for your own.

Browsers soon will have most of jQuery underhood:
http://caniuse.com/#search=querySelector
http://caniuse.com/#feat=dom-manip-convenience
http://caniuse.com/#feat=once-event-listener
So i will cringe.

I am just having my own opinion.

[jmcclell]

@Enelar Bloating is really not the issue here, in my opinion. The issue is that a hard dependency on jQuery precludes easy compatibility with modern JS frameworks such as Angular, React or, say, Elm.

I don't know how one fixes this in a way that could make it more easily compatible, mind you, but that is my concern. When using one of these frameworks, one of the core tenants (especially of React which actually enforces it!) is that the underlying DOM and VirtaulDOM must be in sync. If we are using Semantic UI components (dropdowns, for instance) which rely on JS+jQuery to modify the DOM out-of-band with regard to React's rendering process, we hit a wall. The components, thankfully, do have hooks which can be used to work around this problem, as the docs demonstrate for the React case, but it is still less than ideal.

So, while I don't have much of an opinion with regard to bloating, and I, unfortunately, do not have any solutions to offer at this juncture, I think it's important that we focus on the more pressing issues that a dependency on jQuery creates. I don't believe bloat to be one of them.

[sethlivingston]

I second @jmcclel. If something isn't needed (and jQuery is not needed), and if that something also causes compatibility problems, then it needs to go.

[cortopy]

@jmcclell totally agree. It's what I said above too. Angular 2 is very similar to React. It has its own rendering process to transit from shadow to light DOM. Adding jQuery goes against all the foundations of the framework.

[levithomason]

React Compatibility

@jmcclell @sethlivingston Compatibility with React is unrelated to jQuery. Consider:

$('.ui.dropdown .menu').addClass('visible')

const menu = document.querySelector('.ui.dropdown .menu')
menu.classList.add('visible')

jQuery uses the same DOM APIs everyone else does. Using jQuery or vanilla DOM APIs makes no difference. At the end of the call stack, browser DOM APIs are manipulating the DOM. Using DOM APIs is not "the React way". Per React:

React provides powerful abstractions that free you from touching the DOM directly...

These abstractions _are_ the Virtual DOM. React basically rewrote the DOM. You cannot solve the React integration issue by any other way except using React itself as the JS implementation. This is why we created Semantic-UI-React. It doesn't use the DOM, it uses React's abstractions, the "Virtual DOM".

Angular2

Adding jQuery goes against all the foundations of the framework.

Then, like React, this is must also be true of using vanilla JS, since jQuery just calls vanilla JS under the hood. If Angular2's render process is not compatible with jQuery or vanilla JS, then it seems work is needed in Semantic-UI-Angular2. Though, I did a lot of jQuery integration in Angular 1 and it is claimed that "using jQuery from Angular2 is a breeze compared to ng1."

If jQuery were removed, what is the proposed replacement JS that would solve Angular2 issues?

Is Removing jQuery Worth It?

I agree it is better to not depend on jQuery. But, I haven't see a valid pragmatic argument that justifies the cost of rewriting the entirety of SUI jQuery to vanilla JS. It would take a _team_ several months and introduce new bugs and browser compatibility issues. Compatibility issues would have to be solved with the same browser APIs and logic that jQuery is solving them with. This effort would remove jQuery only to then rewrite all the parts of jQuery that SUI is using (which is most of it). This doesn't seem like time well spent.

Even if completed, if your framework of choice does not play well with DOM manipulation, then this effort offers no gain to you.

Proposal

Specialization

I believe the more beneficial approach is to keep core SUI just as it is, a great framework for traditional HTML/CSS/JS applications. Allow frameworks and libraries to use any of the HTML, CSS, or JS that their paradigm allows. Semantic-UI-Ember for example is a thin wrapper on top of SUI, whereas Semantic-UI-React has no jQuery nor SUI JS at all.

Less talk, more do

Action is the best way to affect change. Lead the charge, if your endeavor has merit, others will help. Props to @avalanche1 for trying to coordinate action in https://github.com/Semantic-Org/Semantic-UI/issues/3981 to remove jQuery. So far, it appears people do not truly want to remove jQuery and are only willing to cavil about doing so.

Smaller, Focused, Bite-sized Efforts

We need to narrow this down. Proposing a massive task like "remove jQuery" as a blanket solution to size optimizations, React/Angular2 integration, and mobile performance is not a valid approach. It is too broad to accomplish anything.

If the issue is package size, there should be an issue focused on this alone. It should include a detailed analysis of SUI package size and incremental steps to improving that.

If the issue is speed, there should be an issue focused on this alone. It should include perf analysis and a hot list of areas to fix.

If the issue is mobile performance, there should be an issue focused on this alone. It should include mobile perf analyses and a prioritized hot list of areas to improve.

Finally, if the issue is integration with a particular framework or library, first check the existing integration repos in Semantic-Org. If there one missing, open an issue focused on this integration alone.

---

If the community really cares about these issues, I believe this is a more effective approach to take. Otherwise, it looks more like removing jQuery for the sake of removing jQuery and grasping for justifications.

[jmcclell]

@levithomason I actually generally agree with you here. As I said in my post, I do not know of how one could fix the issue of compatibility/inter-op with modern JS frameworks. The existing hooks are certainly a step in that direction.

I think it's a larger issue, and not one that Semantic alone faces. It's not the dependency on jquery, it's the requirement to manipulate the DOM for some of the UI functionality. Is there a way of doing that which would be more compatible and flexible than the current way? I don't know the answer to that question.

Removing jquery, in and of itself, as you point out, is not really solving anything.

[Enelar]

@jmcclell on any jQuery site try to store some selector in variable, and then replace body content. And then try to find child/parent etc, on removed element. You will notice that they do not have html parent, but they are still present. Because they are in DocumentFragment.
(Google Chrome 54). Documentation update is pending: https://github.com/jquery/learn.jquery.com/pull/725

So jQuery perfectly works with DocumentFragment aka "VirtualDom"

[jmcclell]

@enelar I think perhaps you've misunderstood the issue. The problem lies in the reverse. If my purely functional JS framework's VirtualDom representation expects the real DOM to look one way, but jQuery has modified it behind its back, I've now got a VirtualDom that is no longer in sync with the real thing.

How much trouble this actually can or does cause, in practice, is debatable, but it's a problem that exists.

Even in the direction you refer to, if I re-render the real DOM via my VirtualDom-based renderer and it overwrites the real DOM, even if jQuery's variable still has a stored copy of the previously rendered DOM fragment in memory, it's not very useful if, say, that fragment is where I've placed my hook for something such as a dropdown action.

Currently, in order to use Semantic UI with Elm, I am using a small hack where I continually listen for DOM change events in jQuery and re-apply .dropdown(), .checkbox(), etc. methods to the appropriate selectors when they are added/removed so that Semantic continues to function.

[Enelar]

@jmcclell sounds like bad designed framework. Let me explain.
With jquery it is ok to create elements:

var my_var = $('<div></div>');

And you just created _real_ thing. It yet not attached to DOM but its real.

$(document).append(my_var);

my_var.detach();

Your expectation that jQuery working with DOM-attached elements only, is wrong. As long as i remember, wrong since jQuery 1.1. So i disagree with your point.

I could give my_var into your_function(my_var), and you should never assume that it attached to "real" DOM. It just matter of encapsulation. BTW it is huge offtopic, knock at my email pls.

[jmcclell]

@Enelar It is off-topic, agreed. I've no need to continue the conversation, however. It just appears that we are mis-communicating with regard to terminology more than anything, eg: VirtualDom.

[levithomason]

@jmcclell The issues you are facing with Elm are identical to what we faced with React. Both use a similar virtual DOM implementation. We also tried to use SUI jQuery lifecycle methods to sync the two, but in the end, it just isn't practical (especially for the dropdown). IMO, the best path forward at this point in web history is to create Semantic-UI-Elm repo. Unfortunately, React and Elm use different virtual DOM implementations so we couldn't reuse Semantic-UI-React code.

I do agree it would be awesome to somehow abstract SUI hooks to support any choice of render stack. Something akin to moving SUI core to a DOM-Hook-Only based architecture with adapters for React Virtual DOM, Elm virtual-dom, and jQuery. I'd be super interested in pioneering some research with you if there is enough community interest in this. Basically, a generic JS component specification.

[levithomason]

Apologies for continuing an off topic discussion. However, @Enelar's comments while bold are completely incorrect. I'm afraid they're severely misleading to others.

Real vs Virtual DOM (TL;DR below)

The distinction between the real DOM and Virtual DOM has nothing to do with what was said. They are entirely separate APIs and data types.

The Node is the base interface for most DOM types. The Element inherits from Node and represents an object of a Document. The HTMLElement inherits from Element. Finally, the HTMLDivElement inherits from HTMLElement.

Therefore, a <div> is the real DOM because of it's type. Regardless of what created it, what memory references it has, or whether or not it is attached to another node. It is a document object of type HTMLDivElement, an instance of Node.

The DocumentFragment also inherits from Node, which by definition makes it exactly the real DOM. Stating "DocumentFragment aka 'VirtualDom'" is equivalent to saying "String('1, 2, 3') aka an 'Array'", just because it is a comma separated list. It couldn't be more "not an array".

jQuery operates only on the real DOM

jQuery is just a wrapper around browser APIs. Both create real HTMLDivElement objects, instances of Node:

var jqDiv = $('<div></div>')[0]
var docDiv = document.createElement('div')

console.log({}.toString.call(jqDiv))
console.log({}.toString.call(docDiv))
//=> [object HTMLDivElement]
//=> [object HTMLDivElement]

console.log(jqDiv instanceof Node)
console.log(docDiv instanceof Node)
//=>  true
//=>  true

Then what _is_ the Virtual DOM?

In loose terms, the real Document Object Model is an API and set of types for working with Document objects (for us, the browser's document). Loosely, the Virtual DOM is an API and set of types for creating _plain objects that only describe_ what a real document looks like. You are creating _virtual_ document elements that _represent_ real document elements. You never actually create an element that inherits from Node nor does it live in a real document. Virtual DOM elements are just plain JavaScript objects.

This is true of both the React (Virtual) DOM and the virtual-dom project which powers Elm.

Notice, the API for creating elements is not the same nor are the returned elements the same type as browser document elements. They're just objects.

var reactDiv = React.createElement('div')
console.log({}.toString.call(reactDiv))
//=> [object Object]

console.log(reactDiv instanceof Node)
//=> false

TL;DR / Conclusion

The real DOM is made up of instances of Nodes and includes the browser document and it's elements. jQuery is an abstraction on top of this API. The Virtual DOM is made up of plain objects that describe what a real document should look like. They are two completely separate APIs with completely separate types and objects.

Neither jQuery nor the browser have an API for creating virtual DOM elements. Virtual DOM solutions do not provide APIs for directly creating or manipulating real DOM elements.

For clarity, none of this has anything to do with the native Shadow DOM utilized by Angular2.

[levithomason]

.....aaaaaaaand, I think we should close this issue and open little tiny focused issues where we can get stuff done 👯

[controversial]

Right. Creating nodes that aren't in the main DOM isn't a special jQuery feature, it's present in vanilla JS with document.createElement. This capability is not what is meant by virtual DOM, @Enelar

[sethlivingston]

Agree with @levithomason haha, but will add: Maybe SUI's primary contribution is a specification for how UI components should be constructed and styled and implementations are left up to different projects. Question is, what form would that specification take?

[levithomason]

I'm not completely sure of the spec or abstraction, but I think of how SUI has brought consistency and beauty to component markup via a semantic language. It would be interesting to explore something similar for the behavior of components.

Naive first ideas come in the form of defining lifecycle hooks and events for components and their component parts. If this abstraction could somehow be implemented, perhaps adapters could be made from it. Each adapter might wire SUI spec'd component life cycle hooks and events into a React component, an Elm component, or jQuery selectors/methods.

Seems the abstraction would be responsible for associating html classes to components and component parts. This way, the abstracted interface could inform an adapter that when the menu receives click then the new classes are menu active and the component is in the "menu-open" state.

This is obviously contrived and incomplete, but I hope it gets the rough idea across. Generically associate components/component parts, with their events, classes and a given set of states. Then, allow the implementing framework/library to ingest the spec and create the components.

[jmcclell]

@levithomason This is exactly what I was half-baking in my brain. I don't have a grasp on what it would actually look like, but intuitively I feel like we can do better - that such an abstraction could be created.

[levithomason]

Cool, I'm seeing it now. If you wanted to start a repo testing this idea out, I'd be willing to try and help grow this fragile idea to see where it goes.

[Ryuno-Ki]

Sounds interesting. It would be interesting to mention this issue on that repo/put a link to it in here.

[hendricha]

Random question: How would (Could?) stardust function with https://github.com/Matt-Esch/virtual-dom or would it require React?

[levithomason]

Stardust is a set of React components that render to valid Semantic UI markup. React has its own Virtual DOM implementation. So, Semantic-UI-React (Stardust) uses React's Virtual DOM. There is no way (or reason) as far as I am aware to switch the Virtual DOM implementation to the one by Matt-Esch.

It is worth noting, virtual-dom claims to have been inspired by React:

Original motivation

virtual-dom is heavily inspired by the inner workings of React by facebook. This project originated as a gist of ideas, which we have linked to provide some background context.

So, they are similar in approach and spirit. Though, I don't think you'd want to try to replace one with the other.

[ansarizafar]

VueJS is simple and next jquery. Semantic ui written with Vuejs +1

[dreampod]

We have done all the components as described without using jQuery. In it's current state it is designed to work on react-rails but when it's out of beta and we can release the npm / gem package and it could become open source. The roadmap for us is not very clear yet, but I appreciate the Semantic-UI react project even more as we have had to solve a lot of the same problems :)

[levithomason]

@dreampod would love to collaborate on any possible React component problems you've run into and solutions you've implemented. We now have nearly 100% component support. We continue to grow in stars and collaborators at a regular rate as well.

[ivantcholakov]

I think that a jQuery-based repository should exist in the future anyway. Have a look at Aurelia framework, it seems to offer progressive code transition without conflicts with jQuery.

[levithomason]

Agree, see https://github.com/Semantic-Org/Semantic-UI/issues/1175#issuecomment-229401450. Though, this is not feasible with React specifically. http://react.semantic-ui.com/introduction#jquery-free.

Jack is working toward some really great long term standards for the web, specifically, a UI component spec. I'm hoping it takes root and is adopted. If so, it will lend itself exactly to something akin to https://github.com/Semantic-Org/Semantic-UI/issues/1175#issuecomment-244635034.

Speaking of ^ @sethlivingston, in a recent email chain with Jack he indicated he is working on precisely this. Pretty exciting.

[franciscolourenco]

By implementing using react you are replacing one dependency with another.

On 2 Dec 2016, at 23:49, Levi Thomason [e-mail] wrote:

Agree, see #1175 (comment). Though, this is not feasible with React specifically. http://react.semantic-ui.com/introduction#jquery-free.

Jack is working toward some really great long term standards for the web, specifically, a UI component spec. I'm hoping it takes root and is adopted. If so, it will lend itself exactly to something akin to #1175 (comment).

Speaking of ^ @sethlivingston, in a recent email chain with Jack he indicated he is working on precisely this. Pretty exciting.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[italomaia]

What about making semantic-ui jquery-slim compatible first, then, work your way down ... ?

[levithomason]

@aristidesfl This thinking is backward. Semantic UI didn't add React as a dependency, React's ecosystem gained Semantic UI components.

jQuery and React are two incompatible paradigms that require two incompatible implementations. You cannot replace one with the other.

[levithomason]

@italomaia This is not a bad direction and one I would approve of personally.

Though, I'm still of this mind: https://github.com/Semantic-Org/Semantic-UI/issues/1175#issuecomment-244566222.

[franciscolourenco]

@levithomason You can try to paint it differently but, can you use SemanticUI modules without either jQuery or React, just with vanilla JS? If not, those sounds a lot like dependencies to me.

[levithomason]

Can you use vanilla JS modules in React? Nope. Vanilla === DOM, React === virtual DOM.

[franciscolourenco]

@levithomason that doesn't make sense. We are talking about using SemanticUI without jQuery and without React.

[levithomason]

Sorry for the off topic discussion, you had raised the point and I felt compelled to correct it:

By implementing using react you are replacing one dependency with another.

React isn't related to removing jQuery in any way, though, the points raised in this very long running issue span several points. I think a good summary is https://github.com/Semantic-Org/Semantic-UI/issues/1175#issuecomment-244566222.

There needs to be a willing and able dedicated team to take this on.

[franciscolourenco]

Ok, just to clarify if I understood correctly:

1. Does the React version still use jQuery?
2. Is there a version which doesn't require React or jQuery?

[levithomason]

1. No. http://react.semantic-ui.com/introduction#jquery-free
2. Not that I know of.

Out of curiosity, what is the use case for excluding jQuery as a viable option?

[multivoltage]

Is still now jquery included as dependency? If I type $(selector) it works so I think yes.

[GuacheSuede]

6109

[rhamedy]

I wanted to use Semantic-UI for a project and then I came across JQuery dependency and all a sudden it didn't feel right. I guess I will stick with Bulma for now.

[tomdavidson]

The intro claims to be JQuery free. Should this be closed? @rhamedy where did you find the JQuery dependency?

[necmettin]

No, actually the React integration is jQuery free. Semantic-UI is jQuery dependent: https://semantic-ui.com/introduction/getting-started.html check the HTML code towards the bottom.

On 1 February 2018 at 23:59:20, Tom Davidson ([email protected]) wrote:

The intro claims to be JQuery free. Should this be closed? @rhamedy where did you find the JQuery dependency?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[kspeakman]

The primary way I use Semantic UI is in CSS only form with Elm. @jlukic has done a great job making nearly all elements controllable through CSS classes, which fits very easily into VirtualDom-based frameworks. Previously, the documentation did not make it obvious which classes to apply to control the behavior, so I would have to play with the controls on the site and inspect the DOM to see. But now the docs mostly have this information.

Aside from triggering animations with CSS classes (Transitions section), I can't think of an element that I had to avoid using because it required jQuery.

Edit: Some elements like Search/Rating still do not document the classes needed to control the states without jQuery.

[therealglazou]

I would support a de-jQuery-ification. Semantic UI is a superb library (I hate the word 'framework') I'd like to use inside a WebExtension we build but jQuery inside WebExtensions raises issues, some being quite painful.

Daniel (former W3C CSS WG Co-chair)

[morganbarrett]

I'm rewriting a fork to remove the jQuery dependency, it's about time someone did something about this mess. You can follow it's progress here:

https://github.com/morganbarrett/Vanilla-Semantic-UI

VIVA LA VANILLA

[pocesar]

do we have any plans for this? the issue was closed 4 years ago, would be good to rethink / revisit some "set in stone" ideas

[Atulin]

Don't think there are any plans for that. Unless guys who maintain FomanticUI want to surprise us 😄
SUI is, for all intents and purposes, one man's endeavor. I wouldn't count on anything that requires rewriting a large part of the codebase, be it removing jQ or making the theming system sane. In forks we trust!

[domenkozar]

@jlukic if people start contributing JS components without jQuery, would you accept PRs? I'd do it for dropdown.

Another Elm user, loving semantic UI and really the only thing that bothers me so much is jQuery.

[gerardmrk]

Is there an official list of components that utilises jQuery? I'd like to help remove the jQuery dependency, unless it's deeply integrated.

[Atulin]

Seeing how you initialize pretty much everything using the stuff like $(".dropdown"), I'd say everything requires jQ.

[morganbarrett]

@gerardmrk head over to vanilla semantic UI and contribute there

[domenkozar]

See https://github.com/fomantic/Fomantic-UI/issues/319#issuecomment-451770599 for ambitious plans at Fomantic

[Dzefo]

I was really looking forward to using Semantic-UI from the moment I heard about it, but JQuery is a real dealbreaker. Please consider removing JQuery as a dependency.

[alexboor]

2020
have been used semantic in several projects in the past.
Now starting a new one and have to find a way how import jquery to my beautiful and clean es6 project? It's painful, really.

[kspeakman]

@Dzefo @alexboor Please see my previous comment. Semantic UI is usable purely in CSS form. See npm package semantic-ui-css. Even the animations are controllable with declarative CSS classes, though you may want to keep animation state on your model to remove transient animation classes when done. (Although we use animate.css for animations, which is CSS only.) What could use some improvement here is documentation explaining how to use the current jQuery-specific sections as CSS only.

[hdasdoria]

@kspeakman What about modules like dropdown? I still haven't found a clean way to use dropdown on <select> element without jquery.

[kspeakman]

@hdasdoria You use the same technology that you are already using for handling button clicks, input changes, etc. If you are already using jQuery, then keep using it. Only the Semantic lib doesn't have to make you require it specially. All of the states are controllable with only CSS classes. But these are not well documented or rather are documented as "call jQuery in this way" instead of the actual classes used.

For drop-downs we use the plain select and onchange events (in React) and let the browser render its animations. Or we use the constructed drop-down with just onclick events on the individual items to handle value changes. Using "select" to construct an JS-based dropdown is just using select as a source of values but is actually rendering its own separate UI with divs. You could do that just as well as it could if you knew the exact classes to use and you would retain more control over it. And doing so is actually easier when using techs other than jQuery.