Hacker News Reader

Comment by preommr | Hacker News Reader

I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale.

react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sugar (vue has jsx support).

react is fundamentally about 'inputs changed, render this'. This got rid of a lot of issues with poor code because frameworks had crappy DX (angluar 1 scope nonsense, and overengineered DI concepts), and people were bad at tracking side effects because a lot of people just wanted a search bar with some cool features and not everyone was building sophisticated products.

That setInterval example is fundamentally against what react is, and is basically svelte/vue/(react + mobx).

View on HN

> react is fundamentally about 'inputs changed, render this'

I mean, pretty much all frameworks these days have that fundamental declarative model, react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc)

What the setInterval example highlights is that newer subsystems in React like useEffect and Suspense are bolted on top of earlier iterations that weren't originally designed to support these kinds of semantics, and the dissonance between API design iterations has become noticeable. This is a pain point that is relatively unique to React.

The growing popularity of Svelte and Solid are largely because their API designs align naturally with how people expect features to work, without people falling into pits of failure like stale closures and incorrectly wired dependencies. React is popular and it puts bread on your table and all, but pretending it doesn't have warts doesn't do anybody any favors.

> react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc)

React was absolutely a breath of fresh air when it was released.

Knockout was similar to Solid.js in that they both have functions that you call which then log a data dependency, then when the data changes the UI updates. This led to lots of pain, because instead of a plain value, you have functions which return values, and you need to be very careful about when those functions are called, otherwise the data dependency might not be tracked properly.

Angular had a similar issue, as its state-based observation relied on special scopes. Updates in the wrong scope could be lost or delayed.

React’s approach of only diffing the rendered UI rather than trying to drive updates based on diffs of the input data was vastly simpler, it was much easier to understand the data flow through explicit state and props.

We also had ractive.js, we had mithril, intercooler.js (now htmx), we even had (fab).js as far back as 2010 with functional rendering. A 'breath of fresh air' pretty much depends on what you had been breathing.

React wasn't exactly innovative as such so much as it was a very carefully designed (I don't mean they didn't make mistakes, mind, only that they clearly put effort into making new and exciting mistakes) implementation of the model that successfully broke into the mainstream.

The phrase "an idea whose time had come" springs to mind.

(this comment is intended to read as professional respect, not fanboying - the extent to which I succeeded in that intension must inevitably be left as an exercise for the reader)

> they clearly put effort into making new and exciting mistakes

Very good.

React also requires that you call functions to trigger rendering (be it via setState or `[, setFoo] = useState()`) and it definitely has warts that trip people up too (e.g. semantics of calling setState twice synchronously). The dependencies array in useEffect is also conceptually the same mechanism you claim causes pain in Knockout.

IMHO, historically, the bigger pain point with the reactive model was data marshaling/unmarshaling (e.g. updating some subtree of data and then needing to send the root of the data tree to the server while maintaining reactive bindings across a large app and being careful not to fragment source of truth). Ironically, React can also end up in this predicament, because the encapsulation model of its `state` mechanism means extracting the actual state of the component tree is non trivial unless you're using a third party state lib to avoid it altogether in the first place, or at least use useReducer, which is a relatively new addition to React (and even then, it's kinda jank).

These days, React is a hodge podge of many different implementation approaches. Yes, there are props, but Context also exists - and is used extensively in the wild - precisely because props get clunky, and then there's data diffing happening to support `memo`, on top of the virtual dom change tracking. Suspense basically requires your code to adhere to semantic restrictions, i.e. you're not even in control of when your component function is called, which leads to having to tip-toe around that scope w/ extra closures, which in turn leads to all the issues that the article touches on.

The hodge podge issue isn't specific to React; Vue is also seeing pain points from having so many ways of doing things now that they're trying to push a v3 and realizing ecosystems tend to slog.

To your point, yes React was relatively simple when it came out, but as I mentioned, it wasn't the first to take a stab at the declarative model, nor the simplest. It just benefited greatly from the popularity wave of the golden years of Facebook OSS engineering. And from a practical perspective, it doesn't really matter what React was. Idiomatic usage is a thing, and React development today isn't like React development 7 years ago.

This is just iteration on the awesome groundwork that React laid, and shows that things can still be much better. React has some very peculiar patterns that don't really jive well with javascript as a language, or its ecosystem. If the setInterval example is fundamentally against what React is, then IMO that really hammers the point the author is making. I have a few React projects under my belt, and often times still find myself confused by hooks or the mess that I create when I use them.

In my personal opinion when there is a lot of complicated state in a component and there is no real benefit to splitting it up into smaller components then hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code), however in my experience whenever I come to place nowadays this would be considered heresy and everything needs to be in hooks even if you have 10+ and growing number of hooks to make everything hang together.

Maybe, but in my experience whenever I encounter an incomprehensible mess of hooks it usually ends up because devs were not using all the tools that react provides.

For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer.

Components that don’t benefit much from splitting up could have their business logic wrapped into a context, and let the view code be just jsx without all the interweaving of code and templates.

Maybe the one benefit of classes was like it forced you to think in business logic, then render. React still has that, you just need to dive a bit deeper into its toolbox.

The result usually turns out much more flexible - contexts neatly wrap business logic for all of its descendants, classes don’t.

I think this was maybe because react actually allows you to write messy code, and it’s still performant and works. But in the end it just kinda postpones the inevitable maintenance burden.

I guess solid.js from the looks of it might postpone it a bit more. I just worry that solid looks more like magic, and some invariant somewhere will just break and I wouldn’t know what sequence of reactions actually led to that infinite loop that crashed the page. Haven’t tried it myself though, might more understandable in the end…

> For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer

You've just deoptimized your app, and your whole component will re-render on every change.

> Components that don’t benefit much from splitting up could have their business logic wrapped into a context

You did it again. More unnecessary re-renders.

> it’s still performant and works

True that 'it works', but it's usually not as performant as you think - we just have really fast computers and phones now.

>You've just deoptimized your app, and your whole component will re-render on every change.

If you have 3 useState each of those will use 3 useReducer internally (every hook is implemented on top of useReducer), If you consolidate them into one useReducer then you will end up with the same thing performance wise. Maybe even better. Whenever an event is pushed into the hook's queue it marks the component as dirty. The next call to useReducer will then reduce all unprocessed events into the current state. It's entirely possible that having less hooks and therefore less metadata in the background can improve performance more than avoiding the theoretical cost of rerendering a component that most likely would have to be rerendered anyway.

Not all hooks are implemented in terms of reducers. `useMemo`, `useCallback`, `useRef` for example are not based on reducers, (or effects). Obviously the effect hooks are based on effects not reducers, and some like ` useDeferredValue` are based on both.

But you certainly are correct that useState is reducer based. I'm pretty sure one is only avoiding rerender via using multiple `useState` if they don't implement the reducer in a way where it returns the original object when there was no net change. If you are able to implement the such that it only returns a new object when there really is a change, then a single useReducer call is strictly more efficient than multiple useStates. (This might require more complicated code, as returning a new object every time is often the easy way to implement reducers.)

Why is performance always argument No. 1? The true rule is, code must be readable and maintainable first. THEN, if there are performance issue with the code (no theoretical ones, you HAVE to have a real-world profiling report of YOUR code in your hands when you argue about performance), you can refactor for performance.

A thing I remind myself of regularly: Avoiding worrying about optimisation up front too much is not avoiding caring about optimisation at all, it's reserving the number of hours you can expend on optimisation until you have enough working to have a profile available, because you are inevitably going to be wrong about which part is actually slow until that point so your optimisation hours budget will be better spent with a profile in hand.

There's a parallel here to "no, you did not find a bug in the compiler". Yes, ok, once every five years or so I actually did find a bug in the compiler, but assuming you aren't that smart is still a far far better default approach.

That's a straw man argument - I did not say it's concern #1, just pointing out that React forces that specific trade-off. Balancing complexity, maintainability, AND performance is really hard with hooks, the lack of built-in reactivity and inefficient baseline behaviour. It's rarely a matter of "just combine it into one reducer".

On top of that, profiling and optimizing a real world application with a dozen hooks in every component is pretty painful.

“Long lists of generic hooks” is a symptom of devs not having climbed the difficulty curve a bit further, to where they are writing custom hooks, and using fewer in each component, IMO.

It’s understandable to stumble into this difficulty though, and a bit of deceptive marketing on the part of the hooks folks. They should be upfront that using hooks well in a real app requires a lot of careful thinking of the kind that many “typical” programmers do not have much practice in, and then the maintenance of whatever code comes from the effort. The functional-programming-mindshare situation seems to be improving slowly, but still.

hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code)

If the lifecycle methods you're referring to are things like componentWillReceiveProps or getDerivedStateFromProps then the React blog covers why they were problematic https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d.... It was very common for developers to make things that would repeatedly rerender when other parts of their app updated. Hooks make that far less likely to happen.

That said, I agree that a getDerivedStateFromProps method is more readable and much clearer than useEffect(()=>{ // stuff }, [big, list, of, props]);

that a particular way of doing things was problematic for the community as a whole when measured across all usages does not invalidate the observation that there were some usages in which that particular way seemed better.

when, as I often encounter, organizations mandate all hooks all the time they are not throwing the baby out with the bathwater, but they are maybe throwing out the baby's rubber duckie without considering that might be useful to have around at times.

When you have multiple hooks in a component it usually makes sense to put them in a function with a good name - a custom hook. It's easy and almost always usually gives simple code.

sure, and sometimes it still would be simpler with the older lifecycle methods. Not saying it is always the case but for some reason it is assumed it could never be the case.

a benefit of custom hooks is that you can test complex state logic isolated from the view

The thing is that While react is against side effects, javascript is not. Which result in these impedance mismatch where what devs want is against react itself.

Vue/svelte/solid do not fight against js, hence they do not end up in similar situation

React lets you build DOM with normal JavaScript loops and .map; solid requires its own For element. How do you define “does not fight against js”? Because the above feels likes solid fighting against js.

Fully agree.

With React, "plain JS" works just like I expect it to. If I have an event handler that does `x = foo` then I don't expect my component to re-render. Why should it? I'm just changing the value of a local variable. If I want to re-render, there's no way to express that in plain JS, so I'll use React's API and write `setX(foo)` instead. Now it's clear that it's not just changing the value of a local variable, but using React's API to do something else.

With Svelte, writing `x = foo` doesn't just change the value of a local variable. Maybe it's going to run a bunch of magic to update a piece of the DOM instead. Or maybe I need to prefix it with `$: ` which in plain JS is a label for a continue or break statement, but here doesn't mean that at all and means reactivity instead.

Oh, and to conditionally render an element, instead of writing idiomatic JS like `condition && <Element />`, I now have to write `{#if condition} <Element /> {/if}`.

WTF. What looks like plain JS is now magic, and what should look like plain JS such as conditional rendering and lists are now some contrived templating constructs.

And almost everyone here is telling me that I should find that simpler somehow.

It makes zero sense.

Sorry for the "+1" chain but I want to express my agreement as well.

Especially when I compare it to Svelte and Vue (not solid, solid.js is just... good), if I look at a component, with react it's way easier to say what's going to happen.

Aren't there gotchas? Yes, but sometimes it's just stuff JS lacks, and so does React.

I'm very excited about Records and Tuples in JS to help with the immutability, for example: https://github.com/tc39/proposal-record-tuple

Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion.

SolidJS splits it between <For> and <Index>. <For> is equivalent to passing the object as the key and <Index> is equivalent to passing the index as the key.

https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_index

> Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion.

That's one of the design decisions I don't fully understand. It knows that there should be a key there so why just not put it there silently and let me override it when I need, instead of screaming at me when I omit it.

The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-ch...

And it also goes into why index is a poor key (it's basically the same behavior as with no key).

Using object identity to detect inserts doesn't work either, because the map function is returning new React element objects on each render.

Practically speaking if you know your items won't change, then omitting the key or using index is fine.

So SolidJS has this solved elegantly? It lets you choose between object identity and index, and it doesn't have that caveat for object identity because it knows what's going into <For> and not just what's coming out of it.

Don't omit the key in React unless you want warnings.

I know, I've read it. I'm still not convinced. React could just as well generate and insert missing key on build instead of asking me to do this:

... you can add a new ID property to your model or hash some parts of the content to generate a key.

It is just plain wrong to ask me to change my data model because of this. This is part of the housekeeping that I expect the framework -- pardon, library -- to take care of for me.

It can't. Not in a consistent manner. When diffing user provided immutable data you need a user provided key. Otherwise it can't tell the difference between a new list entry and a nested update. You could treat every nested update as a new item but that is incredibly wasteful as it throws away all descendants. This is something all non-fine-grained rendering libraries have to deal with be it React, Vue, Svelte, or Lit.

How does Solid avoid the need for user-provided keys? I thought it also had to diff the underlying array. Does it check object identity?

It does. Just referential check. Our reactivity is nested and we don't want blow out everything so even though there is read/write segregation and immutable interfaces the internals are mutable. In so sorting looks at referential equality, and nested updates don't even trigger list diffing.

Now this does require special process for intaking immutable or big data snapshots where we can't do reference comparison. So we do have a data diffing capability in our nested reactive stores to propagate only what changes. But for the most part common actions like partial updates highly optimized. As well as simple list operations like sorting.

It’s a performance pitfall. The warning is trying to make sure the dev correctly tells it how to and when not to re-render.

Could it silence the warning? Yes. However, the React devs choose not to. I think it’s the correct default, but likely needs a more educational warning message.

i'm finding a hard time articulating what you said, if React is against side effects then useEffect wouldn't have existed and we wouldn't have data fetching.

React is unique in that everything in the component is within the render path, while the rest of the frameworks (that you've mentioned) doesn't.

you might be mistaking "side effects during render is bad" for "side effects is bad", the two statements are not the same.

I mean side effects from a functional point of view. Let me explain in more details

React’s philosophy is View = F(data)

I.e. view is a pure function of data. By “pure”, we mean F() does not do console.log, ajax calls, date time and other stuff which is not consistent every where.

This assumption is ingrained in React. You see it when you are told that react can overrender and your code should handle overrendering. And react works well when user code is pure. However, real world does not work that way. So, there is a need to handle side effects, so that “side effects” works well with pure function assumption of react. This “handling of side effects” is the over head introduced by react.

Other js frameworks (svelte, solid, vue) do not assume full immutability or pure functions, hence User code does not need special handling for these cases

> View = F(data)

That's just how templates are meant to work. Underscore.js templates don't allow making an AJAX call before calling render() either. https://underscorejs.org/#template

Consider following scenario:

User is entering an account register form. When the user has entered a value in nickname, your app must check if it is in use and display error message if the nickname is already in use.

Sounds good, and ubiquitous right? Well, that also require an ajax call to server for validation, so it breaks the pure function assumption right there. Now, you what do you do?

The template's render function doesn't make the AJAX call - not in React, and not in Underscore templates.

When you display the error message, yes, React provides a way to do that without re-rendering the input box and while keeping the contents, but many react devs are skipping the traditional React way of doing that and using react-hook-form instead.

I get what you're saying about the component's data updating the state of the DOM in a way that resembles pure functions, but I think AngularJS did it before React, and that Backbone was not far from this vision. Certainly there are a zillion JavaScript frameworks that do this now, and only React has you jumping through silly hoops like "className" and "htmlFor". https://preactjs.com/guide/v10/differences-to-react/#raw-htm... https://www.solidjs.com/tutorial/bindings_classlist

> so it breaks the pure function assumption right there

There's no pure function assumption being broken here. React is a framework for rendering UI from state and coordinating updates to that state. That's why we have things like `useEffect`, contexts, and so on. The only part of React that is expected to be free of side effects is rendering.

Put another way, given your example, React just says that you shouldn't issue your Ajax call in your rendering code. Instead, you should do it in response to an appropriate action, such as a change event on your form controls.

I fail to see the purity in react with all that useState, which obviously by the name is tracking state outside the scope of the function(eg: it's actually View = F() and data is coming from outside when calling useState). It's not pure at all. I really would like to see something more akin to Elm, where all your state is explicitly passed into the component, and you have commands that update state and trigger the view again, making it actually "functional". I guess this takes the form of redux in react, but I'd like to see it ingrained in the components themselves.

Yes it's var View = F() and var hidden_global_variables_for_hooks;

> React’s philosophy is View = F(data)

Yeah internal component state throws all of that out the window.

That's lit-htmls philosophy, not react. React is all about bundling the view and state and then marathon profiling sessions to figure out why everything is re-rendering all the time.

> All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sugar (vue has jsx support).

Honestly, the boon of React is just how easy it is to create components, or at least how simple things were back in the day - it is exceedingly composable, moreso than AngularJS, Angular or Vue have been, at least in my experience. In React, your component can fit within a single file, containing simple syntax, especially for when you're making a pure functional component with no side effects or hooks. And even when you need to add something more complicated, you just have a method or two to change, essentially "progressive enhancement" for your code.

Though admittedly state management, or at least our current approaches to it ruin everything with endless boilerplate (Redux, Vuex etc.) to address an issue that may or may not be easier to represent, though some libraries certainly try (MobX comes to mind).

Of course, my experience leads me to agree with the article, in how React in combination of hooks sometimes is problematic, although in my case that was primarily because of render loops and how the stack traces are akin to JDK 8 NullPointerExceptions, where you couldn't see exactly what's causing you problems: https://blog.kronis.dev/everything%20is%20broken/modern-reac...

I'm probably wrong in liking class based components since those have other issues and Vue/Angular both feel a bit less productive in comparison, even if sometimes easier to reason about, with different tradeoffs to them. Maybe i should check out Svelte some day, but i guess it's all just one long slog of finding what works for you and what doesn't, much like it is with back end programming languages or even relational DBMSes.

Zustand has solved the complexity of state management for me, although getting {employer} to adopt it is of course a different problem altogether.

It's really bizarre to me how poorly useContext works, in contrast to how good everything else in React is for the most part. Having a good, "official" global state management solution that requires little boilerplate would be a huge benefit.

I am currently most fond of mobx / mobx-state-tree which is a substantially different style but I am very much impressed by zustand as "take the redux style and do it really well".

There are enough different takes on how to state management that I am ... ambivalent ... about whether having a single official solution would in practice be better than the current situation. It's inevitably going to be a trade off and the react team not wanting to pull the trigger on such a thing until they're -really- sure is probably a good thing overall.

As a side note: I agree that useContext is weird, but jamming what (at least according to the mental model I use when working with it) is dynamic scoping into a language without native dynamic scope is probably always going to be at least somewhat weird.

Wait till you realize Zustand does not work on React 18's Concurrent Mode and istead must use Jotai (same author) ?

Zustand 4 already works with Concurrent Mode. Still in beta, but so is React 18.

I enjoy React+MobX with class-based components, because they are nearly as nice as Seaside was, back in the day!

> In React, your component can fit within a single file

Furthermore, a lambda local to a function can be a full-blown component (visible in DevTools etc.).

So if you need a component that is used in only one other component, you can neatly encapsulate it and make it invisible from the outside, which can be useful on occasion.

> react is fundamentally about 'inputs changed, render this'.

The actual article acknowledges that when it's read: "React isn’t truly reactive."

And the author also claims to love React and to think it made things better.

You're arguing with phantoms.

React was about bringing a more immediate mode UI programming model to the web, as opposed to retained UI programming models are a PITA to work with. Retained doesn’t work well in games, it doesn’t work for productive UIs either.

That's not completely correct. React is, and has been from the start, a UI rendering library. Its fundamentals are component abstractions, the component tree, lifecycle, the virtual DOM. We had other declarative frameworks before React (Ractive.js, svelte's spiritual grandfather, being the most popular one).

The 'inputs changed, render this' paradigm (and by this I mean reactivity, not the declarative model) has been around for much longer and is exactly what this post is about - React doesn't really do that, since it relies on you to explicitly tell it, via dependency arrays or setState calls, when to re-render. It is not fundamentally different from `.on('change', this.render)` code we were writing back in 2010, just a lot of syntax sugar on top.

That React managed to sell itself so well, while not actually delivering on the reactivity or performance promises, is the surprising part. I'm excited for the future as we finally move on from this era.

Hrm.

"React as Schelling Point" ?

I keep my sanity by ignoring all of them, focusing on mastering pure Web standards only, and delving into such frameworks only when I am required to collaborate with Web FE devs.

I recently started to look at native web components (custom elements), at first I thought I could replace {insert your framework here} with it, but it seems that it doesn't solve the issue, you still need some kind of framework built on top of it to achieve the same goal.

If you have some recommendations or want to share your experience with working only with web standards I want to read them :)

Easy, Java and .NET SSR frameworks (which support components for two decades now), + vanilaJS for Ajax like behaviours.

Loads fast, easy to debug without tons of layers in the middle.

And yes, I also do manually make use of script and vendor JS libraries.

Naturally it only works when doing side gigs on my own, on big Web projects where my role is mostly BE/DevSecOps, I go with the flow.

That isn't a solution. Everybody moved away from this approach for web applications for good reasons.

The craziness of SPA frameworks running headless browsers, rediscovering SSR as if they are inventing something that no one else thought about, proves otherwise.

Having been on this ride since before HTML was a thing... I'm going to make a prediction: JS SSR will be a brief flash in the pan. In another ten years, we're going to look at it the same way we look at JSF today. "What were we thinking?"

Given the WebAssembly adoption rate of frameworks like Blazor, plenty of people miss JSF and WebForms today.

I agree, I am writing some apps like that and we still want some minimal level of interactivity that is suited to react. E.g. a file uploader.

Well, I think when they moved away, they also increased the complexity of their applications as well.

This is about "feels like" and me too--the little newsletter popup and lack of substance shows this. React became obsolete over the past few years as browsers increasingly adopted the mix of web components features (eg componentDidMount vs connectedCallback). Just using React, and the explanations for why a technology is and isn't used in an organization speaks to the level of practical knowledge and detritus in projects. That products survive this long with React illuminates how resistant the community is to... reading and doing work in the easiest, pragmatic way possible. Like why bother writing an article like this?

That is a big call regarding web components. I did some looking into web components for a recent project and React is just way ahead in many areas. You could use a framework like Lit to help smooth things over, but that just speaks to the underlying standard being somewhat cumbersome to use. I totally want web components to succeed and be the new way of doing things, but I get the feeling that is still a while away.

I think calling web components "cumbersome" belies the intention of the APIs, which is to enable custom HTML elements, encapsulation, and interop - fairly low-level concerns.

Lit takes care of templating and reactivity. Web components don't have those, it's expected that you use other methods, including what you already use, to create DOM and react to state changes.

The DOM may eventually add templating and reactivity, but that's a pretty big question given how many approaches and syntaxes there are. Until then libraries are fine and allow for multiple opinions.

Only a clarifying point to add about Lit: tagged templates provide templating and have native support, all Lit does is provide API extensions for reactivity, ie state management. So when a portion of a template is associated with an object, only that part is updated due to how the libraries work. And this is fundamentally all the it provides (unless I've misunderstood something). Lit-html provides functional state+template views while LitElement provides the OO/class oriented lifecycle approach--collectively now rebranded as "Lit". https://lit.dev/ Please call out corrections as needed.

Big call? I suppose there's a point where having done enough work in projects affords some perspective. Whenever anyone gets the feeling to do something else the docs will probably be there, as they were the past few years.

I've been maintaining a web component library with Lit for a while. Web components overall don't feel ready for primetime. Just making a custom input field and have it work with a <form> is chore.

Just look here at how much overall code is needed to do it right: https://github.com/ing-bank/lion/blob/master/packages/input/...

After you get through all the inheritance and mixins it's thousands of lines

I only have this generalized experience to respond with (at the moment): For the private project i work on full-time, the few dependencies related to ING and Lion were the most problematic and the first to get ripped out. I have no idea about the specifics of your dependency, and will not review the work you're mentioning in detail. However, ING, based on my limited experience, is nothing to base any assumptions on. Based on my limited experience, ING and Lion appear to be distinctly inferior examples of work done with Lit and web components. That was my first and last time working with anything Lion and ING related.

That's just one example, and the issues with form associated components are not limited to ING. The Microsoft FAST form components also have a fuck ton of code to achieve what <label> + <input> can do in any non-webcomponent framework.

There are proposals for this and most of the other issues I have with web components. But they all feel like issues that could have been covered from the beginning.

Also if you go all Lit on an app with many nested shadow doms it becomes fairly painful to test with tools like cypress.

What is your point--or question? Form elements are complex. I'm not familiar with cypress. Puppeteer has worked fine for my needs. If the thesis is simply that using web components is a chore, well, welcome to frontend work. It has always been a chore in one way or another. Web components are the first time I can say--for my own professional experience--it was less so than previously. Generally a superior experience to all of: React, Angular, Backbone, jQuery, etc. Maybe you just need to hire me? I couldn't say without more detail.

> That products survive this long with React illuminates how resistant the community is to... reading and doing work in the easiest, pragmatic way possible.

My point is that you were entirely wrong. Web Components are not ready for primetime, they are half baked. If they were the easiest and most pragmatic way possible to build web applications people would do so.

The only thing they are the easiest and most pragmatic for is to build a simple non-form associated component that can be used across frameworks. Like a card.

> It has always been a chore in one way or another.

It's actually never been a chore to make an <input> behave properly. Something that literally every component library needs to do.

Slightly dismissive, but I agree the setInterval function was a little misleadingly contrived.

The transition to functional components was to reduce the coupling between abstract functionality and DOM-related lifecycle events.

React hooks are mostly about expressing where and when you want to memoize a value, with the default being not to.

Once you learn what to look out for, and properly designing and review codebases at scale, these trivial issues don't happen all that often. Additionally, being able to specify memoization parameters explicitly brings extra flexibility and some additional design patterns.

What are you talking about? The setInterval example is completely idiomatic React hooks. It is literally given in the React docs:

https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-...

Reading it now, the language I used was inappropriate. You're correct, the stated problem is common with registering and triggering self-repeating and timed loops.

That was really my point, don't do that.

The original angular worked perfectly for me, but that's because I loaded the source code onto my tablet and read the entire thing top to bottom over a few evenings in a pub beer garden with a cigarette and a pint to keep me company.

Newer frameworks are absolutely better for anybody who isn't sufficiently batshit enough to do that, but much though I enjoy react + mobx (especially react + mobx-state-tree) I've never got to the "I have the core source code in my head and can mentally dry run it as a desk check type operation when debugging" stage with them like I did with early angular so - with the level of jank inherent in its scope nonsense entirely acknowledged - I still occasionally miss it even so.

(this is mostly me being nostalgic, I think, the newer stuff is absolutely better but that was a fun few evenings and for its era damn but I could make that thing sing)

I think for progress you need to look outside the js world. Fundamentally, people keep repeating the same mistakes there.

I'm having a lot of fun lately using Kotlin-js for example. We use the Fritz2 framework, koin for dependency injection (popular on Android as well for good reasons), and fritz2 relies on kotlin's co-routines and StateFlow for state management. It makes for a surprisingly concise code base. For example, the counter example from the article with that would look something like this:

  class CounterStore : RootStore<Int>(0) {
    val koinCtx by lazy { GlobalContext.get() }

    // handler that you can bind events to or invoke directly like below
    val inc = handle { old -> old + 1 }

    init {
        // launch co-routine to keep on incrementing the counter
        GlobalScope.launch {
            while (true) {
                inc()
                delay(1000)
            }
        }
    }
  }

  val koinCtx by lazy { GlobalContext.get() }

  fun RenderContext.counterComponent() {
    val counter by koinCtx.inject<CounterStore>()
    h1 { +"A Counter" }
    // react to changes in the counter
    counter.data.render { currentCount ->
        p {
            +"Current count: $currentCount"
        }
    }
    pushButton { 
        icon { arrowUp }
        events {
           clicks handledBy counter.inc
        }
    }
  }

  fun main() {
    startKoin {
        modules(
            module {
                single {
                    CounterStore()
                }
            })
    }
    render("#target") {
        counterComponent()
    }
  }

There's a lot going on here that I can't explain here. But having co-routines means having a proper reactive framework that you use to react to events and update stores, which is where you keep your state. counter.data is a so-called StateFlow; the render function maps updates in that flow to the dom. In the example I have both a button and a co-routine updating the store via a handler lambda function.

Using koin here, just means keeping glue code out of places where it doesn't belong. It's technically optional but makes a lot of sense in larger applications. Because components are extension functions on RenderContext, I use a global variable to get to the koin context. That allows me to inject my dependencies into components with a minimum of fuss. Where Fritz2 gets fun is with more complex state using data classes, lenses, validators, routers and a few other things. And they also take care of styled components and they even have a nice component framework that you can use. Not for everyone and there's a bit of overhead in terms of download size. But great if that less of a concern.

The way mobx-state-tree uses generators as a coroutine-like affordance is worthy of study.

I would not at all be surprised or troubled if, having studied it, you still dislike it, but there are definitely ideas in there that I consider to be at worst -interesting-.

>GlobalScope.launch { ... }

I can't begin to express how sad that makes me. Your component should have its own scope that it destroys when it gets destroyed, otherwise your coroutine leaks to the outside world when your component is gone from view.

Sure, but I wasn't going to fit a whole lot of boiler plate in a comment on HN to do that. Using Globalscope in a demo is perfectly valid; a lot of co-routine presentations do that as well. Normally, I'd use some named scope and life cycles associated with e.g. koin modules or a web worker. This is just something that I quickly knocked out that actually works. Also, this is not Android. There are not a whole lot of life cycle events beyond "page loaded".

Reply on news.ycombinator.com