281–290 of 313 posts
JQuery is cool because it does not try to replace the HTML. Progressive_Enhancement / Graceful Degradation is possible with jQuery, something which the new Frameworks, Svelte, React, etc., have forgotten / never learned.
Vue can do progressive enhancement.
Earlier quoted context omitted.
As a non Elm lover, Why is that? I think you could freeze every JS frontend framework in time right now and use them for the next decade. JS is very backwards compatible. It's the ones that do some kind of server connection that introduce vulnerabilities and need active development.
It's stuck in time, has no support, only core devs can expose newer DOM apis (and when I say newer I mean released in the last 6/7 years). Very hard to hire for, not LLM friendly.
But again, I don't think no support matters. How many DOM apis do you know of in the last 10 years that are essential? There are sites on JQuery 2 running fine.
Earlier quoted context omitted.
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…
How exactly is Vue better? It just introduces more artificial states, as far as I see. My major problem with React is the way it interacts with async processes, but that's because async processes are inherently tricky to model. Suspense helps, but I don't like it. I very much feel that the intermediate states should be explicit.
Their setup (component) functions are a staging ground for wiring up their primitives without you having to worry about how often each call is being made in your component function. Vue 3's composition pattern was inspired by React with hooks, with the exception that variables aren't computed on every render.
And I agree about Suspense, it's a confusing API because it's yet-another-way React forces you to nest your app / component structure even further, which creates indirection and makes it harder to tie things together logically so they're easier to reason about. The "oops, I forgot this was wrapped with X or Y" problem persists if a stray wrapper lives outside of the component you're working on.
I prefer using switch statements or internal component logic to assign the desired state to a variable, and then rendering it within the component's wrapper elements -- states like: loading, error, empty, and default -- all in the same component depending on my async status.
Earlier quoted context omitted.
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. > N…
Even if you make a `createProvider` factory to initialize a `useMyContext` hook, it still requires what I mentioned above.
Compare this to Vue's Pinia library where you can simply create a global (setup) hook that allows you to bring in other hooks and dependencies, and return the final, global state. Then when you use it, it points to a global instance instead of creating unique instances for each hook used.
Example (React cannot do this, not without enormous boilerplate and TypeScript spaghetti -- good luck!):
export const useMyStore = defineStore("myStore", () => {
const numericState = ref(0);
const computedState = computed(() => reactiveState.value * 2);
const numberFromAnotherHook = useAnotherHook();
const { data, error, loading } = useFetch(...);
const derivedAsyncState = computed(() => {
return data.value + numericState.value + numberFromAnotherHook.value;
});
return {
numericState,
computedState,
numberFromAnotherHook,
derivedAsyncState,
}
});
Every other 3rd party state management library has to use React Context to initialize store data based on other React-based state/data. Without Context, you must wait for a full render cycle and assign the state using `useEffect`, causing your components to flash or delay rendering before the store's ready.
Earlier quoted context omitted.
How exactly is Vue better? It just introduces more artificial states, as far as I see. My major problem with React is the way it interacts with async processes, but that's because async processes are inherently tricky to model. Suspense helps, but I don't like it. I very much feel that the intermediate states should be explicit.
I think it's a matter of taste and preference mostly, but I like Vue's overall design better. It uses JS Proxies to handle reactive state (signals, basically) on a granular level, so entire component functions don't need to be run on every single render — only what's needed. This is reflected in benchmarks comparing UI libraries, especially when looking at table row rendering performance. Their setup (component) func…
I understand that mixing declarative UI with the harsh imperative world is always problematic, but I think I prefer React's approach of "no spooky action at a distance".
As for speed, I didn't find any real difference between frameworks when they are used correctly. React can handle several thousand visible elements just fine, and if you have more, you probably should work on reducing that or providing optimized diffing.
For example, we're using React for 3D reactive scenes with tens of thousands of visible elements. We do that by hooking into low-level diffing (the design was inspired by ThreeJS), and it works acceptably well on React.Native that uses interpreted JS.
Earlier quoted context omitted.
I think it's a matter of taste and preference mostly, but I like Vue's overall design better. It uses JS Proxies to handle reactive state (signals, basically) on a granular level, so entire component functions don't need to be run on every single render — only what's needed. This is reflected in benchmarks comparing UI libraries, especially when looking at table row rendering performance. Their setup (component) func…
I tried proxy-based approaches before (in Solid) and I _also_ had a lot of problems with async processes. The "transparent" proxies are not really transparent. I understand that mixing declarative UI with the harsh imperative world is always problematic, but I think I prefer React's approach of "no spooky action at a distance". As for speed, I didn't find any real difference between frameworks when they are used corr…
I find React perfectly acceptable, it's just global state management and a few flaws with its lifecycle that repeatedly haunt me from time to time. (see: https://news.ycombinator.com/item?id=46683809)
Vue's downside is not being able to store off template fragments in variables. Every template/component must be a separate component file (or a registered component somewhere in the tree), so the ease of passing around HTML/JSX conditionally with variables is impossible in Vue. You can use raw render functions, but who wants to write those?
JSX being a first-class citizen is where React really shines.
Earlier quoted context omitted.
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. > N…
My issue with React Context is you can only assign initial state through the `value` prop on the provider if you need that initial state to be derived from other hook state/data, which requires yet another wrapper component to pull those in. Even if you make a `createProvider` factory to initialize a `useMyContext` hook, it still requires what I mentioned above. Compare this to Vue's Pinia library where you can simpl…
Your example would look like:
const id = useState(...);
const numericState = useState(0);
const q = useQuery({
queryFn: async (context) => {
const data = await fetch(..., {signal: context.signal});
const derivedState = numericState + data.something;
return `This is it ${derivedState}`;
},
queryKey: ["someState", id],
}, [id, numericState]);
...
if (q.isLoading) {
return loading...;
}
return {q.data};
The downside is that mutations also need to be handled by these libraries, so it essentially becomes isomorphic to Solid's signals.
is there any reason to use jquery if you've never used it before
maybe use Vue or something like mithril which doesn't require build. But jQuery is short and easy to grasp.
Wow, this is interesting to see. I thought jQuery was dead. My next question would be, is this something that OpenAI and Anthropic would train their data on? If I ask Claude Code to write an app and utilize jQuery, would it resolve to the previous version until it's retrained in a newer model?
they have legendary backwards compatibility.
most of the breaking changes are dropping support for ancient browsers.
so yes, LLMs are great with jQuery.