[suggestion] - Remove JQuery

[Olyno]

Hi 👋🏻

Your project is really interesting, but JQuery is kinda deprecated, and not recommanded to be used. You can find more explainations here.

I was starting to make a pull request without JQuery, but i prefer to discuss about it before.

[alyssaxuu]

Yeah, I am aware jQuery is pretty old by this point. But it genuinely makes it so much faster to develop anything. I am aware how to do the same things in vanilla javascript, but it's just longer and not as clear when reading through the code. Using React for such a small extension also feels overkill to me. I don't know, I just don't really see the issue with jQuery I suppose. I've used it for a lot of my projects and it's been great.

[Olyno]

I totally agree JQuery is great to make things fast. The main problem with JQuery that I can see is the space it takes up, space that users could do without:

If the problem is mostly "shortcuts", I can try to arrange to make a pull request proposal and you could tell me what you think?

[alyssaxuu]

I don't think it takes up that much space, besides if using the Google CDN in many cases users already have jQuery in their cache so it doesn't need to download again.

If people genuinely don't want jQuery in the project then I am open to removing it, I just feel like it would slow me down, that is all.

[shengslogar]

Lukewarm take? jQuery gets too much crap. I've been guilty of it myself. But you're really complaining about 114 KB? That's negligible. It's a damn fine library to keep using and I wish I hadn't completely abandoned it.

Keeping kicking ass 🙌

[cecicifu]

If you want something similar to jQuery but better and lighter, can use Cash instead jQuery. Check it out.

[alyssaxuu]

If you want something similar to jQuery but better and lighter, can use Cash instead jQuery. Check it out.

Cash seems good. That said, I don't know if the issue is about the size really, with the CDN it should be no problem using jQuery. I feel like some people might prefer it to have no dependencies, not sure. Also in terms of contributing to the project, I'm open to whatever makes it easier.

[Olyno]

The main issue isn't really the size of JQuery (even if it's an issue). The main issue is JQuery is deprecated since 2018, and some technologies became more usefull than JQuery (Like Cash)

Filtering issues related to JQuery shows how much of a problem JQuery is:

To give an example: Bootstrap has removed JQuery in its latest version.

That said, JQuery or Cash are not necessarily necessary as dependencies. They only allow you to manipulate DOM elements, something you can already do in vanilla without difficulty.

Again, I'm not against the idea of JQuery, but the fact that it's deprecated doesn't necessarily please me (and doesn't seem to please other developers). Using the Cash alternative seems more appropriate if you really want to keep the JQuery syntax.

[stefanjudis]

The main issue is JQuery is deprecated since 2018

Maybe I'm missing something, but it's not deprecated, though, or? There are still recent commits and the last release is not even a year old.

I'd vote for: use whatever makes you productive. 💙

[yoroshikun]

I would advocate for cash IF its API is similar enough to jQuery to not break your productivity. Cash feels more future proof, smaller and offers typescript compat if that comes down the line. (My personal would be neither but that would require a complete redevelop and learning curve for anyone involved so a no go!)

[alyssaxuu]

Ok, so here's what I tried. First I removed jQuery. I figured it would be easy since I'm only using jQuery on the content.js script, and it's not that long. I quickly encountered issues, had to do some workarounds to handle events for dynamically added elements (since the omnisearch gets injected, and the list keep getting updated), the selectors began getting more complex, and then I got to the following:

down[e.keyCode] = true;
if (down[38]) {
  // Up key
  if ($(".omni-item-active").prevAll("div").not(":hidden").first().length) {
      var previous = $(".omni-item-active").prevAll("div").not(":hidden").first();
      $(".omni-item-active").removeClass("omni-item-active");
      previous.addClass("omni-item-active");
      previous[0].scrollIntoView({block:"nearest", inline:"nearest"});
  }
} else if (down[40]) {
  // Down key
  if ($(".omni-item-active").nextAll("div").not(":hidden").first().length) {
      var next = $(".omni-item-active").nextAll("div").not(":hidden").first();
      $(".omni-item-active").removeClass("omni-item-active");
      next.addClass("omni-item-active");
      next[0].scrollIntoView({block:"nearest", inline:"nearest"});
  }
}

In order to recreate this in vanilla js, it would take way more code. I also saw similar complexity in other parts of the code.

Then I tried implementing Cash, as you suggested. Apparently it is not 1:1 with jQuery, because first of all it wouldn't support $.get() which I had to change into a XMLHttpRequest, but then I kept getting errors, for example it couldn't work with any selectors starting with a colon (e.g. ":hidden"). It just seemed again not as convenient, and requiring way more code to do the exact same thing. I also realized it's not used a lot, it's way easier to find help and documentation for jQuery.

Anyway, what do you think? Like I said, from experience, it is 10x faster to code in jQuery than in plain javascript, especially when dealing with events and selectors (which is why the background script is plain javascript, I don't have to bother with that there). I honestly don't understand the hate for it.

[yoroshikun]

I would suggest keep doing what you are doing and comfortable with. The hate comes with that jQuery is not a modern web framework (dom manipulation) solution, so it lacks a lot of things offered by default by the new generation, performance and features.

[alyssaxuu]

I would suggest keep doing what you are doing and comfortable with. The hate comes with that jQuery is not a modern web framework (dom manipulation) solution, so it lacks a lot of things offered by default by the new generation, performance and features.

Yeah I get that. At first I was considering using NextJs for it, but realized since it uses SSR it doesn't really work for a Chrome Extension, it's a bit complex to make it work. Then I thought about React, but in terms of size React is actually bigger than jQuery, so going by that metric it wasn't the best choice either. I don't know really.

[yoroshikun]

Would you mind if I look into porting this to svelte? Mainly for educational purposes. Svelte due to being compiled is much smaller and requires no lib loading.

If you want to use react you can even use preact as a react developer myself I would advocate this professionally.

These are just options if wanting to swap to a modern framework.

P.S Definitely don't need Next.JS!

[alyssaxuu]

Would you mind if I look into porting this to svelte? Mainly for educational purposes. Svelte due to being compiled is much smaller and requires no lib loading.

If you want to use react you can even use preact as a react developer myself I would advocate this professionally.

These are just options if wanting to swap to a modern framework.

P.S Definitely don't need Next.JS!

Yeah go ahead, feel free :)

Didn't know about preact, sounds interesting, I'll look into it. I'll admit I'm honestly not really a developer myself, I'm actually a designer. My focus is on building many projects (I've created 14+ in a couple of years), so I don't really consider these things when starting a new project, I just think of what would be the fastest way to get the idea executed. I mentioned NextJs as that is something I have been learning lately, I felt it might be worth investing time into, but certainly not for a Chrome Extension.

[yoroshikun]

[Off topic sorry]

100% invest your time into Next.JS (which is a react.js abstraction layer for SSR goodies) I have been using it to good effect for a few years now and can highly recommend it for streamlining web app dev that requires that kind of thing.

I'll let you know what I come up with, and will be applying random optimizations wherever I can for the MVP, I'm going to yoink your designer css and stuff because im not the best at that :)

[brunodeangelis]

I agree to removing jQuery. Could this also fix the slugginess when having too many commands open? For me it lags a bit.

Apart from preact, you could look into https://github.com/vuejs/petite-vue which is the same but for Vue.js, if you feel more comfortable with that.

[Olyno]

There are still recent commits and the last release is not even a year old.

This is my bad, Google isn't up to date and gave me a wrong information, but it still 10 months ago, which is old in the frontend world

it wouldn't support $.get() which I had to change into a XMLHttpRequest

Some advice about it: use the fetch way, it's so much easier and it's the modern way to fetch a resource (POST, GET or any other) 😄

The hate comes with that jQuery is not a modern web framework (dom manipulation) solution

I'm not agree with that @yoroshikun, the "hate" of JQuery (even if personally i don't hate it) is mainly because there is no tree shaking on it. So you're importing more stuff than you need. Also, it seems to give "native performance" (i don't know everything about it, so i just looked what other arguments people give about it)

I totally agree with Svelte. Svelte is a great way to create things, and i'm creating all my new frontend projects with it. But i'm not sure if it's a good idea to migrate the app to a Svelte app, even i would be really happy. It would means a lot of code changes, reactivity rework, and so on....

[yoroshikun]

mainly because there is no tree shaking on it

the lack of treeshaking is a aspect of it not being a modern framework, just one part of many convenience and DX things.

JQuery is a thin layer on top of native javascript, great solution for simple dom manipulation, however because of that it struggles greatly with more complex ui's and absolute lack of virtual dom lest you make your own web framework with jquery which is reinventing the wheel :) (which ultimately requires a very solid understanding of JS)

[yoroshikun]

I think I will have a working MVP of a svelte ver tomorrow see how that feels (dev so fast it will be missing some feature added in the last few hours, just finished migrating and optimizing the background.js)

[DarkEyeDragon]

I really don't get what the problem is... It works... It does what it's supposed to. This is just complaining for the sake of complaining. Sure other frameworks are good, and a new JS framework pops up every day. Yet JQuery is still around. So can't be that bad right?

As stated above, use what makes it easiest for you to achieve what you're trying to achieve.

[yoroshikun]

I finally finished the MVP of the rebuild in svelte, it contains everything except /commands as of now (I got tired and need a break before finishing that tomorrow) Omni Svelte

Again this is just a MVP, to show differences and for myself a learning resource. You do not have to use it. I have ended up cleaning and refactoring most aspects of the program, so feel free to take a look and incorporate things you see fit, beauty of svelte is that its more native js than other frameworks so easy to yoink things.

I hope to have it fully feature complete tomorrow, with cleanup soon after. [Update] The rewrite had really become a thing of its own now, will continue to work to a new MVP [Update] Its a new thing now.

[Olyno]

This is really clean, good job for that!

[Tooluloope]

@yoroshikun Does this fix https://github.com/alyssaxuu/omni/issues/49?

[yoroshikun]

@Tooluloope Not currently, but I have figured out a fix for it that I will be implementing in the rebuild branch :)