hail to the king
jQuery 4
191–200 of 313 posts
Re: jQuery 4
#192Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?" Anyway, jQuery always did the job, use it forever if it solves your problems.
yes: htmx grew out of intercooler.js, which was based on jquery and inspired by the jQuery.load() method:
which I found while doing some performance work at one point. intercooler.js started as a custom function that hooked .load() in based on custom attributes (a trick I learned from angular 1.x)
deeply respect and love jquery
Re: jQuery 4
#193Earlier quoted context omitted.
This is the part that I find the strangest: > We also dropped support for other very old browsers, including Edge Legacy, iOS versions earlier than the last 3, Firefox versions earlier than the last 2 (aside from Firefox ESR), and Android Browser. Safari from iOS 16, released in 2022, is more modern in every conceivable way than MSIE 11. I'd also bet there are more people stuck with iOS 16- than those who can only us…
“Support” here probably means “we’re testing jQuery for compatibility on those web browsers” - likely Safari from iOS 16 still runs this version of jQuery just fine. However, running automated test suites or support bugfixing for those clients is a lot harder than spinning up some Microsoft-provided VM with IE11 on it.
Also, mobile phones get upgraded/upcycled much faster than desktop.
Re: jQuery 4
#194Earlier quoted context omitted.
You reminded me of a time where one of my clients asked me to add a feature on a file uploader written in react/redux. This was early 2021. I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways, the form literally had a textual input, a button to open the file explorer and a submit button. It took few weeks one of their Romanian team to build it and apparently that team was reassigned…
> I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways I 100% believe this, as it describes all the redux codebases I've seen. The library seems to be an antipattern of indirection.
I really can't understand how someone would make 30 redux actions for a simple use case, as someone has implemented the exact same thing. But yes, not a fan of Redux myself
Re: jQuery 4
#195Congrats 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.
That looks interesting, I'm not likely to write any jQuery any time soon, but I'll check out the source code to see if I can learn anything from it.
Regarding adoption levels, the JsViews website made me think I had accidentally toggled the "Desktop Site" option in my Iceweasel browser, I wonder if that scared people off. Or perhaps it's because, as others mentioned, most jQuery development these days is in legacy codebases where the devs are not allowed to add any new libraries, reducing the adoption rates of any new jQuery libraries even more than you'd expect based on the raw nrs of jQuery users.
(the website does work though, and it loads fast. Which is something I've always appreciated about jQuery based sites still alive today. The only thing I'm missing is any indication of how big it is when minified + gzipped. EDIT: jsrender.js is 33.74 kB, jsrender.min.js a mere 12.82 kB)
Re: jQuery 4
#196Re: jQuery 4
#197Earlier quoted context omitted.
Microsoft will support IE 11 until 2032.
My reading is that they’ll support Edge’s IE 11 compatibility mode until then, but that IE 11 is already EOLed except for a couple of extremely niche enterprise versions.
The IE 11 desktop application remains supported on a number of Windows LTSC versions: https://techcommunity.microsoft.com/blog/windows-itpro-blog/...
At least one of them, Windows 10 IoT LTSC, will receive support until 2032.
Re: jQuery 4
#198Earlier quoted context omitted.
What's wrong with React? It made it so much better to build apps vs. spaghetti jQuery. I still have nightmares about jeeping track of jQuery callbacks
Complex APIs that require intimacy with internals with their gotchas. Complex rendering model and hard to tame lifecycle since they ditched the class component. Very hard to get performant websites (but you're free to link me what you've produced with React and prove me wrong). Also, biggest issue: severely misused for websites that are mostly static content and are nowhere near "app-like" nor have any particular rea…
In 2021, they published a post[0] about how they used web components, alongside a library called Calalyst. It seemed like quite a nice system. I've still seen include-fragment elements in the HTML, so I assume they still use it.
[0]: https://github.blog/engineering/architecture-optimization/ho...
Re: jQuery 4
#199Earlier quoted context omitted.
The problem with React IMHO is it’s so dominant and so annoyingly over-engineered for many problems. I use Mithril and find it much less fuss.
When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess. Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses. These are a direct result of React's poor component lifecycle design. Compare to Vue's granular lifecycle hooks which give you all the control you need…
I'm all for people avoiding React if they want, but I do want to respond to some of this, as someone who has made a few React apps for work.
> When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess.
Hooks didn't fundamentally change anything. They are ways to escape the render loop, which class components already had.
> Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses.
Maybe because you don't necessarily need to. But for what it's worth, I'm on old versions of React when these weren't things, and I've built entire SPAs out without them at work. But reading their docs, they seem fine?
> And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change
I think it's good to give context on what a rerender is. It's not the same as repainting the DOM, or even in the same order of magnitude of CPU cycles. Your entire site could rerender from a text input, but you're unlikely to notice it even with 10x CPU slowdown in Devtools, unless you put something expensive in the render cycle for no reason. Indeed, I've seen people do a fetch request every time a text input changes. Meanwhile, if I do the same slowdown on Apple Music which is made in Svelte, it practically crashes.
But pretty much any other state management library will work the way you've described you want.
Re: jQuery 4
#200Now that's a name i've not heard in a long time...