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

261–270 of 313 posts

Re: jQuery 4

#261

Post by insin »

spartanatreyu wrote: post #242
lopatin wrote: post #94

Earlier quoted context omitted.

The problem with React is that it solved frontend. So the options are to 1. Code React all day and be happy with it. 2. Come up with reasons why it's bad. There are many talented and intellectually curious people in the field which lean towards 2.

It didn't solve frontend, it sold developers one lie (i.e. ui = f(state) ) and managers another (developers are interchangeable gears). Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.

> Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.

It kills me to think of how amazing Web Components could be if those folks had started standardising them _now_ instead of in "competition" with userland component libraries of the time (while punting on many of the essential challenges of developing UI in the DOM those libraries were still evolving solutions for), and introduced more problems entirely of their own making.

Re: jQuery 4

#262

Post by flomo »

epolanski wrote: post #182
flomo wrote: post #74

Earlier quoted context omitted.

Yeah, that's the other HN koan about "You probably don't need React if..." But if you are using jquery/vanilla to shove state into your HTML, you probably actually do need something like react.

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.

Re: jQuery 4

#263

Post by insin »

normie3000 wrote: post #260
gejose wrote: 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.

"We'll build a big centralised store and take slices out of it" still feels like something you should eventually realise your app now needs rather than a starting point, even in libraries which do it without as much ceremony and indirection as Redux.

Re: jQuery 4

#264

Post by jxhdbdbd »

usere9364382 wrote: post #247

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…

I don't understand your comparison at all, SDL is a C library not a C++ library

Are you talking about STL? But even there it makes no sense

Re: jQuery 4

#265

Post by jraph »

janderland wrote: post #234
jraph wrote: post #138

Earlier quoted context omitted.

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 metho…

I'm discussing the "adding a prototype method" case and I'm explaining in my comment why this can be, in fact, an issue.

Re: jQuery 4

#266

Post by bossyTeacher »

mehagar wrote: post #165
bossyTeacher wrote: post #118

Earlier quoted context omitted.

It's overly verbose, unintuitive and in 2025, having a virtual dom is no longer compulsory to write interactive web apps. If you want to write modern web apps, you can use Svelte. If you want to write web apps truly functionally, you can use Elm. React is the jQuery of our times. It was really helpful in the Angular era but we are living at the dawn of a new era now.

How is it overly verbose? I find it very intuitive, with the exception of useEffect.

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)}
    />
  );
} --------------------- Svelte:

export let initialText; let text = initialText;

  $: text = initialText;

Re: jQuery 4

#267

Post by [deleted] »

Capricorn2481 wrote: post #221
epolanski wrote: post #185

Earlier quoted context omitted.

Recommending Elm in 2025 is nonsense and I say it as an Elm lover.

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.

[deleted]

Re: jQuery 4

#268

Post by epolanski »

Capricorn2481 wrote: post #221
epolanski wrote: post #185

Earlier quoted context omitted.

Recommending Elm in 2025 is nonsense and I say it as an Elm lover.

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.

Re: jQuery 4

#269

Post by w4rh4wk5 »

JoeyJoJoJr wrote: post #258
usere9364382 wrote: post #247

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…

Wait, SDL is no longer relevant? What is the alternative?

SDL is very relevant. Not just on PC, also on consoles as ports for all modern consoles are available to platform disclosed developers. (See READMEs in SDL repository.) Calling SDL outdated / irrelevant is definitely an overstatement despite most developers using UE or Unity nowadays.

Re: jQuery 4

#270

Post by DaanDL »

bossyTeacher wrote: post #266
mehagar wrote: post #165

Earlier quoted context omitted.

How is it overly verbose? I find it very intuitive, with the exception of useEffect.

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?
Post reply on HN