Live data from Hacker News

Show HN: A JavaScript UI library for imperative JSX

npmjs.com

51–55 of 55 posts

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

#51

Earlier quoted context omitted.

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…

I appreciate the RxJS observables approach with similar built-in cleanup, but also ways to build higher-level tools and compose things together. interval(1000).pipe(…)… Puts the timer up front and center. There's some confusion between "hot" and "cold" to deal and sharing with, but the pipelines eventually clean themselves up and the higher-level operators can be very nice to you if you let them.

reactiveX will always have a special place in my heart, but at some point I had to accept that the soup of switchMap, combineLatest, distinctUntilChanged wasn't fun for anyone on the team but me.

If we ever get native stream support in JS, I believe it will be closer to hooks than to rxjs.

Signals could actually be a good middle-ground with how they are pull-based, automatically infer dependencies, don't require complicated Syntax like switchMap and combineLatest, and give more control to the consumer (batching, memoization).

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

#52
post #50

This is jQuery-like. Just syntax sugar above the imperative DOM API. Looks like the younger generation didn't know the pain of years of imperative UI "frameworks" and needs to learn this the painful way. Enjoy!

I wrote jQuery from 2009-2016

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

#53
post #31

Thanks for sharing, neat. This makes me curious about the psychology of declarative vs imperative, and why some people gravitate towards one or the other (at least with UI code). Back in the jQuery days, a lot of my hatred towards "JavaScript" was actually imperative UI code in hindsight. In the years since, I now enjoy declarative UI more but see some developers bang their head against declarative UI frameworks. It'…

I also enjoy declarative UI. I hated imperatively building up the interface with jQuery, even with the helpers it just felt so tedious. This library is my attempt to have my cake and eat it too. Like I love being able to just write hello world in my javascript, it feels very nice. At the same time, with React I absolutely hate it when I do things that are inherently imperative. A prime example is the following: I hav…

The only thing that is awkward imho is the focusing, the rest is a really good fit for declarative, e.g. here's your list of "things", render a UI for each.

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

#54

Earlier quoted context omitted.

I appreciate the RxJS observables approach with similar built-in cleanup, but also ways to build higher-level tools and compose things together. interval(1000).pipe(…)… Puts the timer up front and center. There's some confusion between "hot" and "cold" to deal and sharing with, but the pipelines eventually clean themselves up and the higher-level operators can be very nice to you if you let them.

reactiveX will always have a special place in my heart, but at some point I had to accept that the soup of switchMap, combineLatest, distinctUntilChanged wasn't fun for anyone on the team but me. If we ever get native stream support in JS, I believe it will be closer to hooks than to rxjs. Signals could actually be a good middle-ground with how they are pull-based, automatically infer dependencies, don't require comp…

Personally, I have a hard time not seeing Signals as just non-conforming Observables missing a bunch of useful operators. They remind me of how much people loved ko.computed() from Knockout (and I've joked at times that Signals are just a return to ko.computed), but then had an awful time debugging the edge cases or fixing the performance from bad dependencies. Hooks maybe lean too much the other side of the spectrum in trying to force manual dependency tracking but maybe making it harder than necessary. ReactiveX-style Observables hit a sweet spot for me in dependency management that is hard to beat, especially once you get into all of those complicated operators like switchMap/combineLatest/distinctUntilChanged that can be very powerful tools in the right hands, especially for things like dependency management and throttling. (Though yes, getting junior developers and some types of teams all on the same page can be the hard part. In general a lot of functional programming gets tot be that way: once over the learning curve it's all gravy, but the learning curve looks like a terrifying roller coaster to many that haven't yet.)

A proper pipe operator or a C#-like "fluent extension methods" approach might help a lot to clean up some of "scariness" of the first hill of the roller-coaster. If we are wishing for ponies, it might even be really nice in JS to have a proper monadic do-notation, even just a limited form like C#'s LINQ syntax (from … in … let … where … select …). "Monadic do-notation" sounds like its own terrible rollercoaster hill, but is a powerful and succinct way that lets you use a (monad) like an RX Observable in a very imperative ("Signal-like" way that is easy to read, even if the underpinnings feel hard to grasp. (LanguageExt for C# is a fascinating example in how it allows using the from/select syntax to do some interesting monadic binding, that I've seen used successfully by junior developers that don't know what a monad is, but know C# enough and find they can read/write the LINQ well enough.)

I've also had some success eventually training junior developers to think in RxJS or ReactiveX in general. Marble diagrams are particularly great for visual learners to better piece together what happens. (I'm a big fan of reactivex.io's Operators pages for that, and RxJS' marble testing-based unit test harness. I've seen a similar library for C# but it didn't support all the parts of RxJS' syntax which I needed. I'd love to see that need met, too.)

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

#55
post #50

This is jQuery-like. Just syntax sugar above the imperative DOM API. Looks like the younger generation didn't know the pain of years of imperative UI "frameworks" and needs to learn this the painful way. Enjoy!

I wrote jQuery from 2009-2016

And I can tell you liked it! It’s fine, but not all of us did!
Post reply on HN