Live data from Hacker News

Show HN: A JavaScript UI library for imperative JSX

npmjs.com

21–30 of 55 posts

Re: Show HN: A JavaScript UI library for imperative JSX

#21
post #2

Can you talk a little about the pain points you encountered, which this presumably solves?

Sure! There are several, but let's take a trivial one - setTimeout. This is an example of something that is inherently imperative, and therefore requires some awkward logic to get it working correctly in React. Here's an article explaining how to do it: https://codedamn.com/news/reactjs/how-to-use-settimeout-in-r... In contrast, here's how you would do it in matry: let someValue = 0; setTimeout(() => { someValue++; s…

This is IMO a great example for React and declarative programming.

> There's no special concept to understand

By not understanding that you need to cleanup timers when your view unmounts, you've introduced a subtle bug that your coworker will discover in 6 months when users report that the counter sometimes increases twice as fast.

I've worked on Angular-like apps before, and storing and cleaning up timers was always a pain point:

  private timer
  private someValue = 0

  onMount() {
    timer = setTimeout(() => {
      someValue++;
      setContent(value is {someValue}

) }, 1000) } onUnmount() { clearTimeout(timer) }
React on the other hand, clearly defines the concept of an effect as something that is initiated after the component renders and then cleaned up. You also keep the setup and cleanup close together, so you don't need to manually store the timer handle.

  const [someValue, setSomeValue] = useState(0)

  useEffect(() => {
    const timeout = setTimeout(() => {
      setSomeValue(v => v + 1)
    }, 1000)
    return () => clearTimeout(timeout)
  }, [])

  return 

value is {someValue}

People often criticise useEffect for being hard to grasp, but it is the perfect essence of how to manage, well... effects in a component-based system.

That's why Vue and Svelte have the same thing: https://vuejs.org/guide/essentials/watchers.html https://svelte.dev/blog/runes

Re: Show HN: A JavaScript UI library for imperative JSX

#22
post #7

That's the worst idea for framework I've seen recently

Seems like others are downvoting you, but I appreciate seeing the sentiment. I’ll just note that the some of the most influential technologies I’ve encountered in my career were initially disgusting to me. I thought React was gross and I thought Tailwind was gross. But now I love them. Doesn’t mean this is going to be good, just that first impressions aren’t everything.

Tailwind is gross. It's just that it's the least gross of the available options.

Re: Show HN: A JavaScript UI library for imperative JSX

#23

JSX without React is also kind of fun: https://medium.com/@victor.dramba/can-you-do-jsx-without-rea... and it's working example at: https://github.com/dvictor/jsx-no-react/blob/master/index.ts...

Yeah this is essentially what I'm doing. Though I'm fighting with rollup in the process. Might drop down to ESBuild if I need it.

Re: Show HN: A JavaScript UI library for imperative JSX

#25

It's cool to see a novel idea like this get prototyped and then opened up for discussion. As others have hinted at, this feels like jQuery with different syntax and more limitations. In its current form, I can't imagine choosing this over jQuery (in part because I already know jQuery, and in part because the limited reach of your selectors feels like it would be a roadblock very quickly). Perhaps you could reshape th…

I have to strongly agree with this. The entire point of react was to avoid all the challenges of old imperative coding of syncing up state with render state. The Dom digging was an absolutely genius idea to stop that nonsense and just render the correct state and let the framework handle the rest.

I wrote a ton of backbone code, and was a major fan of jquery before Dom querying was even a feature of browsers. And once I went react I really fell in love with frontend dev. Frontend is so simple now because of it, while it used to be dare I say more complex than backend back in the day.

Re: Show HN: A JavaScript UI library for imperative JSX

#26

JSX without React is also kind of fun: https://medium.com/@victor.dramba/can-you-do-jsx-without-rea... and it's working example at: https://github.com/dvictor/jsx-no-react/blob/master/index.ts...

Agreed! About 5 or 6 years ago I wrote a library to demonstrate to my teams that JSX a) was not magic b) not limited to React. After that was done I became a little obsessed with making the library the fastest JSX renderer - which I think is still true: https://github.com/i-like-robots/hyperons

Re: Show HN: A JavaScript UI library for imperative JSX

#28
> The structure of your application state ends up being shaped by the UI, when it should be the other way around

I don’t understand this premise at all. Are you saying your UI should be shaped by your application state? That doesn’t make any sense to me, surely the application state exists to implement a desired UI?

Re: Show HN: A JavaScript UI library for imperative JSX

#29

Earlier quoted context omitted.

Sure! There are several, but let's take a trivial one - setTimeout. This is an example of something that is inherently imperative, and therefore requires some awkward logic to get it working correctly in React. Here's an article explaining how to do it: https://codedamn.com/news/reactjs/how-to-use-settimeout-in-r... In contrast, here's how you would do it in matry: let someValue = 0; setTimeout(() => { someValue++; s…

This is IMO a great example for React and declarative programming. > There's no special concept to understand By not understanding that you need to cleanup timers when your view unmounts, you've introduced a subtle bug that your coworker will discover in 6 months when users report that the counter sometimes increases twice as fast. I've worked on Angular-like apps before, and storing and cleaning up timers was always…

> By not understanding that you need to cleanup timers when your view unmounts

I think this library eschews the entire concept of mounting so that point is kind of moot. Will you likely re-invent it again in any non-trivial app, sure, but when you're writing imperative JS it's probably a MPA where code runs top to bottom. Clean up will happen when everything gets thrown away on navigation.

Re: Show HN: A JavaScript UI library for imperative JSX

#30

It's cool to see a novel idea like this get prototyped and then opened up for discussion. As others have hinted at, this feels like jQuery with different syntax and more limitations. In its current form, I can't imagine choosing this over jQuery (in part because I already know jQuery, and in part because the limited reach of your selectors feels like it would be a roadblock very quickly). Perhaps you could reshape th…

I have to strongly agree with this. The entire point of react was to avoid all the challenges of old imperative coding of syncing up state with render state. The Dom digging was an absolutely genius idea to stop that nonsense and just render the correct state and let the framework handle the rest. I wrote a ton of backbone code, and was a major fan of jquery before Dom querying was even a feature of browsers. And onc…

Same, used jQuery for years and had a love/hate relationship with it.

You're correct that React solved the imperative problems from before, but that's not the only factor to consider. You have to weigh the problems it solves against the problems that it causes.

Post reply on HN