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

jQuery v4.0 Beta

blog.jquery.com

Post reply on HN
Print view View original

371–380 of 404 posts

Re: jQuery v4.0 Beta

#371

Post by DrSiemer »

skydhash wrote: post #175
DrSiemer wrote: post #86

Earlier quoted context omitted.

A few years ago I dropped jQuery for plain vanilla js and I've never looked back. Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins", that usually only do what they want to do and not much else. Yes, the vanilla selectors are more verbose, but any half decent code editor will make them just as fast to type. I don't mean to be penantic, but I don't really understan…

> Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins" The great things about these plugins is that you can strip them down to what you need and patch them yourself (remember lib or vendor directory). NPM and build tools make this a chore.

Stripping them down is work, especially with the type of code that can often be found in random jQuery plugins.

It could be argued that avoiding unnecessary work is my main job function. It's a lot more efficient to just get something that already does what I need, without requiring patches. In my experience leaving the jQuery ecosystem made this a lot easier.

Re: jQuery v4.0 Beta

#373

Post by DrSiemer »

gonational wrote: post #102
DrSiemer wrote: post #86

Earlier quoted context omitted.

A few years ago I dropped jQuery for plain vanilla js and I've never looked back. Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins", that usually only do what they want to do and not much else. Yes, the vanilla selectors are more verbose, but any half decent code editor will make them just as fast to type. I don't mean to be penantic, but I don't really understan…

LMFAO every example of "modern" looks like a course in how not to design an API, etc. The jQuery examples are so clean and expressive. Imagine landing on a page like that and thinking, "hey, that 'modern' option looks good." You'll end up with 28KB (jQuery gzipped size) of just extra syntax before you're done with your app, not to mention the additional 160 hours of work. You'll likely be adding 6-700KB of React and…

The code I write these days is cleaner and more readable than anything I did back in the jQuery days. The only thing I add (for bigger projects) is Typescript.

With jQuery it feels like a lot of functionality is hidden away, which can lead to unexpected situations that are harder to debug.

In my experience writing vanilla code takes less time, not more, because I have a better grip on what is happening.

Re: jQuery v4.0 Beta

#374

Post by dvt »

hoten wrote: post #235
dvt wrote: post #154

Earlier quoted context omitted.

The async/await design is absolute garbage and no one will ever convince me otherwise. `fetch` is a particularly egregious example: it has all kinds of insane random quirks that you need to memorize. For example, how do I handle an error there? What's the obvious way to handle it? Is response null or something? Well, not exactly, you need to check for: response.ok; // false response.status; // 404 Um, okay, I get it.…

I don't see how the design of the fetch API relates to async/await being badly designed, can you explain?

For example, `response` can't ever be null (even though it would be totally expected to if the request borks) due to the fact that under the hood, you're dealing with a promise (probably the most boneheaded implementation of asynchronous programming). async/await tries to put lipstick (syntactic sugar) on a pig (promises), and the fetch API, among many others, suffers for it.

Re: jQuery v4.0 Beta

#375

Post by ryanisnan »

anakaine wrote: post #225
midasuni wrote: post #216

Earlier quoted context omitted.

I’m not even sure what I used, it’s the same 5 lines I’ve used for years. Boom bang and on to the next problem. For every unicorn saas webapp $300k a year developers are writing there’s a thousand small pages. If you’re building a house you aren’t going to use a Swiss Army knife, but if you’re camping out for a couple of days you aren’t going to take a van full of power tools.

A couple.of well selected power tools are certainly helpful, however. A battery blower to start the fire, a small electric chainsaw for any wood cutting depending on the area and what you take in, and a portable fan if you're in a hot climate. Sometimes a couple of selected power tools are very helpful.

Weird analogy. I’ve camped my whole life, never once brought a power tool.

Re: jQuery v4.0 Beta

#376

Post by mock-possum »

IgorPartola wrote: post #30
Onavo wrote: post #27

Earlier quoted context omitted.

They just need to add JSX support. Half the reason people use react is because of JSX.

Maybe unpopular opinion but JSX is inferior to something like the Vue templating system. I much prefer to have HTML with some JS sprinkled in than JS that looks like HTML but isn’t.

And vue templates are in turn inferior to lit-html

Re: jQuery v4.0 Beta

#377

Post by hoten »

dvt wrote: post #374
hoten wrote: post #235

Earlier quoted context omitted.

I don't see how the design of the fetch API relates to async/await being badly designed, can you explain?

For example, `response` can't ever be null (even though it would be totally expected to if the request borks) due to the fact that under the hood, you're dealing with a promise (probably the most boneheaded implementation of asynchronous programming). async/await tries to put lipstick (syntactic sugar) on a pig (promises), and the fetch API, among many others, suffers for it.

I still don't know what specifically you'd want different. What would a better language construct be for an asynchronous operation that enabled a better Fetch API in your eyes?

Fetch returning null on a network error just seems the worst possible design, as you don't get any information about why it failed. Raising an error or rejecting the promise seems an appropriate choice for fetch. It failed to reach any server, so it cannot produce a Response object -- but it can raise an error with failure details.

Re: jQuery v4.0 Beta

#378

Post by andirk »

notzane wrote: post #40
andirk wrote: post #33

I like Vue's reactive nature the best (specifically `v-if`, `v-for`), but jQuery was the one that got me over the hump before I actually knew Javascript. And I encourage most projects that use a lot of jQuery to consider using jQuery's CDN version as there is like a 50%+ chance the person already has it cached on their system.

Doesn’t work anymore :( https://news.ycombinator.com/item?id=24894135

Wow! I'm embarrassed I didn't know this since 2020. Too bad we can't allow certain super popular libraries of whose project maintainers we trust to still be cached across domains.

Re: jQuery v4.0 Beta

#379

Post by niutech »

panphora wrote: post #368
niutech wrote: post #367

Earlier quoted context omitted.

> I've always thought there should be a modern, lightweight jQuery alternative like this. Have you heard of Zepto? https://zeptojs.com

Yes, thank you! Zepto is great and it's nice it's jQuery compatible. I've used it before and liked it. However, I guess I was thinking something a bit more modern -- adding more advanced functionality than what jQuery has. Like more array methods for elements (e.g. `pluck` elements based on property values), reactive data stores/templating, a mutation observer helper.

What do you mean by `pluck`? Is it like `array.map(i => i[key])`?

Re: jQuery v4.0 Beta

#380

Post by noduerme »

claytongulick wrote: post #327
noduerme wrote: post #160

Earlier quoted context omitted.

I was going to post on HN not long ago and didn't, about how I still can't find a great event chain handling / bubbling model that lets me use both DOM members and abstract class instances to trigger interchangeable events. I've built my own event dispatchers here and there, but jQuery just does everything right. Although event handling is almost the only thing I still use jQuery for, it's so useful that I still incl…

If your class instances are attached to the DOM somehow, you may be looking for CustomEvents? document.querySelector('#something').dispatchEvent( new CustomEvent('myCustomEvent', {...options}) ); and document.querySelector('#something-else').addEventListener('myCustomEvent', () => {...}); You don't even need CustomEvents if you don't need to carry extra data with the event. You can just do new Event('myCustomEvent')…

Thanks. Frequently though, my class instances are not attached to the DOM ...more often they're purely data classes that receive occasional updates and listen for events from one another. And it's unweildy or impossible to have them all inherit EventTarget as a base class. In any case it's overkill: I just need a fairly simple event loop to track instances, listeners and callbacks (on or off the DOM) and work as a switchboard for events, with the caveat that it's also nice to be able to pipe native events through the same switchboard when applicable.
Post reply on HN