Live data from Hacker News

jQuery 4

blog.jquery.com

301–310 of 313 posts

Re: jQuery 4

#301

For the record, JQuery is NOT to blame for the so called spaghetti code. Most people seem to blame JQuery for their own short coming. Most people also do not seem to understand the genius that was contained in JQuery. See " http://eyeandtea.com/crxcmp " for an example of what could already be done with JQuery in the IE8 era. A lot of the things later invented in the browser were to mask these shortcomings instead of…

Dont get me wrong - I really like and appreciate your comment. However, and adding to other replies, by SDL I assume you mean the Simple Directmedia Layer? SDL looks rather strong from my perspective and still my typical goto when having fun making a game. You could argue SDL lost some customers in favour of other libraries like RayLib - or moving away from making things from scratch to Unreal, Unity, etc. SDL still…

I think STL was the intent.

Re: jQuery 4

#303
post #34

I cannot express how much I admire the amount of effort jQuery puts into their upgrade tools.

I’ve found similar quality in the more recent Storybook upgrade tools - clean CLI wizard, clear error messages, and it does a good job of examining your setup and letting you know what it can and can’t upgrade automatically, with clear instructions on the parts you need to handle yourself.

Re: jQuery 4

#304
post #208

Earlier quoted context omitted.

Surely by this point someone has written a 0-day for MSIE 11 which gets root and silently installs an Internet Explorer skinned Chromium. If not, someone should get onto that. —Signed, everyone

Last available Chromium on XP has 0-days too, so not a big win.

The goal isn’t to make XP machines more secure, so that’s not a problem.

Re: jQuery 4

#305
post #262

Earlier quoted context omitted.

It's not really about state but dom updates.

After having some time to think about it, I've seen some really perverse DOM stuff in jquery. Like $(el).next().children(3) type stuff. So I think this stuff really fell-over when there was 'too much state' for the DOM.

I think if you want to go high-dom manipulation a la jQuery, and want some form of complex state, storing the state _on_ the DOM might make sense? Things like data attributes and such, but I also feel like that’s itching for something more like htmx or maybe svelte (I’ve not looked into either enough, so I may be completely off base).

I do agree with the notion that jQuery is easy to mishandle when logic grows beyond a pretty narrow (mostly stateless) scope. It’s fantastic up until that point, and incredibly easy to footgun beyond it.

Re: jQuery 4

#306
post #228

Earlier quoted context omitted.

This sounds like an engineering quality problem rather than a tooling problem. Well structured redux (or mobx or zustand for that matter) can be highly maintainable & performant, in comparison to a codebase with poorly thought out useState calls littered everywhere and deep levels of prop drilling. Redux Toolkit has been a nice batteries-included way to use redux for a while now https://redux-toolkit.js.org/ But the…

I took a look at the quickstart guide at https://redux-toolkit.js.org/tutorials/quick-start and to me it still seems to add a lot of indirection.

This brought back flashbacks of a brief moment when I was left as the sole maintainer of a “soon-to-be-axed-but-currently-critical” feature in a checkout flow developed by people who A) knew redux and B) were not me. They recently implanted some state updates before departing, and the bugs for that fell to me. I think I spent a few days tracing the code and understanding how they managed their state, and I think I needed to touch about five files to fully encompass the updates for one data point - I felt nuts!

Re: jQuery 4

#307
post #275

For the record, JQuery is NOT to blame for the so called spaghetti code. Most people seem to blame JQuery for their own short coming. Most people also do not seem to understand the genius that was contained in JQuery. See " http://eyeandtea.com/crxcmp " for an example of what could already be done with JQuery in the IE8 era. A lot of the things later invented in the browser were to mask these shortcomings instead of…

> JQuery already had a feature that rendered the shadow DOM unnecessary, but it would require discipline that most developers did not have nor understand. Could you explain this please?

It is the ability that JQuery gave us to scope the css selector to a particular node. If you know POSIX, similar to the "at" functions for filesystems. By CSS child selector, classes, IDs, and what JQuery gave us, you could already develop self contained components, HTML custom elements if you like, without the need for shadow DOM. If you teach people to write well defined CSS, they argue that the CSS is over qualified and similar nonsense. Then the industry turns around and invents the shadow DOM. Any fool can come up with a complicated solution, but the best mind comes up with the simplest. And simplicity is not easy.

Take a careful look at "http://eyeandtea.com/crxcmp", and see how the need for shadow DOM is completely absent.

And this simple thing is just one of the geniuses exposed by JQuery.

Re: jQuery 4

#308

For the record, JQuery is NOT to blame for the so called spaghetti code. Most people seem to blame JQuery for their own short coming. Most people also do not seem to understand the genius that was contained in JQuery. See " http://eyeandtea.com/crxcmp " for an example of what could already be done with JQuery in the IE8 era. A lot of the things later invented in the browser were to mask these shortcomings instead of…

Dont get me wrong - I really like and appreciate your comment. However, and adding to other replies, by SDL I assume you mean the Simple Directmedia Layer? SDL looks rather strong from my perspective and still my typical goto when having fun making a game. You could argue SDL lost some customers in favour of other libraries like RayLib - or moving away from making things from scratch to Unreal, Unity, etc. SDL still…

I do mean SDL, and the discussion is not about its popularity, but about something formal, but perhaps I was not clear. First, yes, SDL is a very good library, and I have referred to them in the past for references about issues related to software architecture.

However, the way I saw SDL 1.x, I am expecting a strong contract. Every now and then SDL drops support for one thing or another. Where you had to worry about different APIs, now if you want to retain your strong contracts, you have to worry about different SDL versions. I am aware of something like the "sdl12-compat" layer for example, somewhat similar to JQuery Migrate, but it does not change the fact that the underlying contract is not strong, is not trustworthy, because of both changing APIs and changing compatibility, similar to the JQuery situation.

Re: jQuery 4

#309
post #270

Earlier quoted context omitted.

React: import { useState } from "react"; function Counter() { const [count, setCount] = useState(0); return ( setCount(count + 1)}> Count: {count} ); } ---------- Svelte: let count = 0; count += 1}> Count: {count} --------------- React: function Editor({ initialText }) { const [text, setText] = useState(initialText); useEffect(() => { setText(initialText); }, [initialText]); return ( setText(e.target.value)} /> ); }…

No one's going to mention VueJS?

I enjoy being a Vue main in these discussions, mostly because everyone leaves us alone lol

I really enjoy the syntax of Vue over React, and if it’s an application that’s complex enough to warrant something like React I’ll almost always reach for Vue so long as it also meets the requirements.

Re: jQuery 4

#310
post #39

Earlier quoted context omitted.

Not everybody in the world can use modern hard- and software. There are tons of school computer labs running old software

Yes, run jQuery 3. Crazy to think that software running inside IE11 should use the latest version of a library.

it's inspiring
Post reply on HN