Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

jQuery 4

blog.jquery.com

Post reply on HN
Print view View original

231–240 of 313 posts

Re: jQuery 4

#231

Post by leptons »

topspin wrote: post #58
maxloh wrote: post #5

Even after migrating to ES modules, jQuery is still somewhat bloated. It is 27 kB (minified + gzipped) [0]. In comparison, Preact is only 4.7 kB [1]. [0]: https://bundlephobia.com/package/jquery@4.0.0 [1]: https://bundlephobia.com/package/preact@10.28.2

> Preact is only 4.7 kB Is there some outlier place where people using virtual DOM frameworks don't also include 100-200kb of "ecosystem" in addition to the framework? I suppose anything is possible, but I've never actually seen it. I have seen jQuery only sites. You get a lot for ~27kB.

I use Preact for a very lean build for a front-end that lives in a small embedded MCU flash ROM. Gziped the whole front-end is about 25KB, including SVG images baked-in to the preact gzip file. I'm very careful about the libraries I include and their impact on the overall payload size.

I had started with a simple front-end that was using jQuery to quickly prototype the device controls, but quickly exceeded my goal of keeping the front-end at under 40KB total gzipped. The problem is needing more than just jQuery, we also needed jQueryUI to help with the front-end, or build out similar complex components ourselves. And as soon as the jQuery code became non-trivial, it was clear that Preact made much more sense to use. Our payload is quite a bit smaller yhan the jQuery prototype was.

Re: jQuery 4

#232

Post by SchemaLoad »

pmontra wrote: post #109
kstrauser wrote: post #80

Earlier quoted context omitted.

According to Cloudflare, there are almost no users still on MSIE of any version.[0] Statcounter says there are about 4.6% of iOS users still on iOS 16.[1] My gut instinct is that there are multiple times more people using iOS 16 today than MSIE of any version. [0] https://radar.cloudflare.com/reports/browser-market-share-20... [1] https://gs.statcounter.com/os-version-market-share/ios/mobil...

I visited a distillery in 2020. Their machines were managed by HP laptops running Windows XP. Those machines and those laptops and that Windows XP are probably still there with their old IE browser.

Those machines are probably not connected to the internet.

Re: jQuery 4

#234

Post by janderland »

jraph wrote: post #138
Sammi wrote: post #136

Earlier quoted context omitted.

Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.

If you are an app or website developer, at least you won't break other's systems. But you might still break stuff in your own projects. Imagine you extend a native prototype with a method, and later the native prototype starts having a method with the same name. Newer libraries start using that new standard method. You upgrade the libraries your website depends on, or add a dependency, and this new code happens to de…

> You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.

He was suggesting adding a prototype method, not replacing one. Unless the library your using is also adding prototypes, I can't think of an issue with this. Sure, if a new version of JS ends up using these names then things could break, but I'd bet this won't cause him a problem in actuality.

Re: jQuery 4

#235

Post by gloryjulio »

hirako2000 wrote: post #215
gloryjulio wrote: post #201

Earlier quoted context omitted.

Many years ago, I used Redux to build real time streaming data processing layer. Basically I need to receive, merge, and process multiple data streams into a single realtime data pool. After that,consuming the realtime data becomes dead easy. Even now I am not sure I could find a better tool to deal with real time data and synchronization. But for simple crud Redux is mostly overkill

https://rxjs.dev/guide/observer

True but rx was even more niche than redux. It was much easier to hire redux devs

Re: jQuery 4

#236

Post by thunderfork »

johanyc wrote: post #86

is there any reason to use jquery if you've never used it before

Generally speaking, no, since a lot of what it does is now available natively, the odds that you'll need something from it are much lower.

There's probably some corner-case stuff it still makes easier if you're not using some framework, but I don't think there's a reason to go out of your way to use it just for the sake of using it.

Re: jQuery 4

#237

Post by Tistron »

Zardoz84 wrote: post #174
hsbauauvhabzb wrote: post #73

Earlier quoted context omitted.

These days I’ve moved to native JS, but hot damn the $() selector interface was elegant and minimal vs document.getElement[s]by[attribute)]. While presumably jquery is slower than native selectors, maybe that could be pre-computed away.

const $ = document.querySelectorAll

I usually do

   const $ = (s, e = document) => e.querySelector(s)
and a similar one for $$.

Re: jQuery 4

#238

Post by sieep »

metaltyphoon wrote: post #158
sieep wrote: post #117

Earlier quoted context omitted.

all these kids chasing the new frameworks...jQuery and .NET framework have always kept me fed!

I mean… jQuery and .NET (6+) can still feed you very well :D

believe me if it was up to me I would get off framework this week hahaha

Re: jQuery 4

#239

Post by shimman »

alnico wrote: post #184

Congrats to everyone involved in the jQuery 4.0 release. For what it’s worth, if you’re looking for a more structured approach on top of jQuery, JsViews ( https://jsviews.com ) provides a reactive templating and data-binding system that’s been around and stable for many years. It hasn’t seen the same level of adoption as newer frameworks, but it may still be of interest to people who prefer the jQuery ecosystem.

Never heard of JsViews but it looks interesting. For other "modern" jQuery approaches, I like cheerio and alpine myself:

https://cheerio.js.org/

https://alpinejs.dev/

Re: jQuery 4

#240

Post by root_axis »

lioeters wrote: post #76
blakewatson wrote: post #20

Related: This is a nice write-up of how to write reactive jQuery. It's presented as an alternative to jQuery spaghetti code, in the context of being in a legacy codebase where you might not have access to newer frameworks. https://css-tricks.com/reactive-jquery-for-spaghetti-fied-le...

This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related. In retrospect, over-engineered React code can be worse than decently organized jQuery code, but some jQuery mess was worse than any React code. So I guess I'm saying, React did raise the bar and standard of quality - but it can get to be too much, sometimes a judicious use of old familiar tool gets the job done.

React made complex interactive UIs a lot easier to manage than jQuery, but that resulted in many developers adding a lot more complexity just because they could.
Post reply on HN