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

A proposal to add signals to JavaScript

github.com

Post reply on HN
Print view View original

171–180 of 336 posts

Re: A proposal to add signals to JavaScript

#171

Post by __s »

pavlov wrote: post #137
Fatalist_ma wrote: post #100

Earlier quoted context omitted.

There is an interesting debate about React and signals in the comments of this article, between Dan Abramov and Ryan Carniato - https://dev.to/this-is-learning/react-vs-signals-10-years-la...

I read it until the point where he defends the idea that these two functions obviously do something completely different: function One(props) { const doubleCount = props.count * 2; return Count: {doubleCount} ; } function Two(props) { return Count: {props.count * 2} ; } It honestly made me wonder whether the article was dated April 1 and I’d been had. More generously, JS framework design is hard. If you’re ambitious…

> There’s no way to know what an apparently simple piece of code will actually do without knowing the specifics of a given framework.

Yes. In solid-js JSX interpolation needs to be read as having implicit lambdas. You need to know how a framework works to use it

It's somewhat what the discussion was getting at between Ryan & Dan. solid-js having fine grained reactivity involves a lot of lambdas, in JSX they're implicit, but code outside of JSX has to spell them out explicitly

Re: A proposal to add signals to JavaScript

#172

Post by andrewstuart »

Pufferbo wrote: post #169
andrewstuart wrote: post #156

Earlier quoted context omitted.

>> In Preact, when a signal is passed down through a tree as props or context, I have found that passing props makes React-like applications very complex and messy and props are to be avoided as must as practical. The mechanism for avoiding props is Custom events. It concerns me to see the concept of signals being passed as props when surely signals/events should be removing the need for props?

You don’t need to pass a Preact signal as a prop to get reactivity. If you’re using Preact, signal references will make your component reactive by default, and if you’re using React you can introduce reactivity by way of the useSignals hook or a Babel plugin. (1) React signals have become my go to state management tool. So easy to use and very flexible. 1: https://www.npmjs.com/package/@preact/signals-react

>> React signals have become my go to state management tool.

I've ditched almost all state in my React apps except state local to the component.

Custom events do all the work for passing information around the application and directing activity.

What do signals give me that events do not?

Re: A proposal to add signals to JavaScript

#173

Post by zero_shift »

berkes wrote: post #149
eddd-ddde wrote: post #30

Earlier quoted context omitted.

Isn't it possible to define all listeners / publishers in a declarative way which can be compiled to catch for this issues?

Yes. It is. And most pub/sub or Observer architectures and design patterns have the "loop" thing solved just fine. In fact, the GOF spend an entire paragraph on the problem of complex update semantics in "design Patterns" (1995) ch Observer p299. So, while it is a real problem, it's one that has been solved (for at least 29 years)

In fact I solved a similar issue in my JS reactive micro library in just 500 bytes: https://github.com/jbreckmckye/trkl

Re: A proposal to add signals to JavaScript

#174

Post by pquki4 »

tambourine_man wrote: post #80
dclowd9901 wrote: post #77

Earlier quoted context omitted.

Decades is a long time. You must remember the complexities of updating the DOM between browsers, surely. Keeping the DOM in sync with a data state isn’t too difficult but doing so in a highly performant (60 fps) way _is_ tremendously difficult. Especially when it comes to creating APIs that aren’t leaky but also not too cumbersome. It would frankly be easier to just paint pixels to a canvas game-style, than translati…

If you need 60fps you shouldn’t use the DOM. It’s not a game engine. Like you said, go with canvas.

60fps is not a high bar. A timer that gets updated every 10 millisecond (or in truth whatever the next event loop interval) is commonly used as tutorial, and there is no reason such a widget does not have a high refresh rate.

The point of the original comment is that DOM updates should be fast, efficient and avoid visible delays to user's eye, which is not easy. If you are not careful, small changes in a large application could lead to too many DOM updates -- that is where frameworks shine.

And canvas is not the solution to everything and has its own problems. To begin with, accessibility.

Re: A proposal to add signals to JavaScript

#175

Post by zero_shift »

tambourine_man wrote: post #74
duxup wrote: post #68

Earlier quoted context omitted.

In simple applications it is easy. More complex it is not easy.

I’ve been writing web apps for easily 25+ years. Never have I reached for React and friends voluntarily. But again, I know I’m in a minority. I’m just not completely sure why.

I think it would help if you mentioned the kinds of applications you're building.

What do you mean by "web apps" here? My memory of the web in 1999 was that the only rich web UX was in Java applets

Re: A proposal to add signals to JavaScript

#176

Post by pquki4 »

tambourine_man wrote: post #74
duxup wrote: post #68

Earlier quoted context omitted.

In simple applications it is easy. More complex it is not easy.

I’ve been writing web apps for easily 25+ years. Never have I reached for React and friends voluntarily. But again, I know I’m in a minority. I’m just not completely sure why.

If you are working in a team with 5+ developers who work on the UI where people need to be able to quickly reuse components and put them in large, complicated applications with lots of data that could be fetched and updated with HTTP requests, it is almost impossible not to use any of those frameworks.

If you are working on your own, or only create small web apps, sure, you can avoid frameworks in some cases.

Re: A proposal to add signals to JavaScript

#178

Post by qudat »

rblatz wrote: post #59

The lack of signals isn’t remotely the largest issue with JS, and adding them has minimal impact for most users of JavaScript. The biggest issue is the lack of a standard library, resulting in npm hell in most projects.

It's getting better. I can build a medium-sized, modern TS/React app with 12 dependencies. A large enterprise app will be closer to 30-40 which is still a marked improvement over previous dep lists.

Re: A proposal to add signals to JavaScript

#179

Post by qudat »

> The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…

This is primarily the only handful of consumers of this stdlib.

Post reply on HN