15 ms·

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 buildin

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).

rk06 5y ago
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
- riwsky 5y ago
  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.
  - benatkin 5y ago
    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_for https://www.solidjs.com/tutorial/flow_index https://www.solidjs.com/tutorial/flow_index
    - ihateolives 5y ago
      > 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.
      - yazaddaruvala 5y ago
        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.
      - wonnage 5y ago
        The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-children 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.
        benatkin 5y ago
        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.
        ihateolives 5y ago
        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.
  - peferron 5y ago
    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.
    - egeozcan 5y ago
      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 https://github.com/tc39/proposal-record-tuple
- intrnl 5y ago
  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.
  - rk06 5y ago
    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
    - benatkin 5y ago
      > 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 https://underscorejs.org/#template
      - rk06 5y ago
        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?
MiddleMan5 5y ago
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.
- stupidcar 5y ago
  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-effect-dependencies-change-too-often https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-...
  - MiddleMan5 5y ago
    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.
joeyjojo 5y 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.
- bryanrasmussen 5y ago
  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.
  - seer 5y ago
    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…
drewcoo 5y ago
> 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.
seanmcdirmid 5y ago
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.
jillesvangurp 5y ago
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.
- ohgodplsno 5y ago
pjmlp 5y ago
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.
- norman784 5y ago
  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 :)
  - pjmlp 5y ago
    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.
    - leonardopainter 5y ago
      That isn't a solution. Everybody moved away from this approach for web applications for good reasons.
      - pjmlp 5y ago
        The craziness of SPA frameworks running headless browsers, rediscovering SSR as if they are inventing something that no one else thought about, proves otherwise.
        stickfigure 5y ago
        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?"
KronisLV 5y ago
> 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-react-is-broken 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.
- VaxWithSex 5y ago
  I enjoy React+MobX with class-based components, because they are nearly as nice as Seaside was, back in the day!
- cehrlich 5y ago
  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.
lhorie 5y ago
> 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.
- DougBTX 5y ago
  > 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.
  - ricardobeat 5y ago
    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.
deleted 5y ago
[deleted]
ricardobeat 5y ago
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.
- mst 5y ago
  Hrm. "React as Schelling Point" ?
jimmont 5y ago
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?
- JoeyJoJoJr 5y ago
  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.
  - jimmont 5y ago
    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.
  - spankalee 5y ago
    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.
    - 5y ago
deleted 5y ago
[deleted]
mst 5y ago
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)

rk06 5y ago

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

riwsky 5y ago
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.
- benatkin 5y ago
  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_for https://www.solidjs.com/tutorial/flow_index https://www.solidjs.com/tutorial/flow_index
  - ihateolives 5y ago
    > 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.
    - yazaddaruvala 5y ago
      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.
    - wonnage 5y ago
      The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-children 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.
      - benatkin 5y ago
        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.
      - ihateolives 5y ago
        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.
- peferron 5y ago
  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.
  - egeozcan 5y ago
    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 https://github.com/tc39/proposal-record-tuple
intrnl 5y ago
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.
- rk06 5y ago
  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
  - benatkin 5y ago
    > 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 https://underscorejs.org/#template
    - rk06 5y ago
      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?

MiddleMan5 5y ago

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.

stupidcar 5y ago
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-effect-dependencies-change-too-often https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-...
- MiddleMan5 5y ago
  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.

joeyjojo 5y 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.

bryanrasmussen 5y ago
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.
- seer 5y ago
  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…

drewcoo 5y ago

> 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.

seanmcdirmid 5y ago

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.

jillesvangurp 5y ago

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.

ohgodplsno 5y ago

pjmlp 5y ago

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.

norman784 5y ago
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 :)
- pjmlp 5y ago
  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.
  - leonardopainter 5y ago
    That isn't a solution. Everybody moved away from this approach for web applications for good reasons.
    - pjmlp 5y ago
      The craziness of SPA frameworks running headless browsers, rediscovering SSR as if they are inventing something that no one else thought about, proves otherwise.
      - stickfigure 5y ago
        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?"

KronisLV 5y ago

> 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-react-is-broken 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.

VaxWithSex 5y ago
I enjoy React+MobX with class-based components, because they are nearly as nice as Seaside was, back in the day!
cehrlich 5y ago
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.

lhorie 5y ago

> 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.

DougBTX 5y ago
> 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.
- ricardobeat 5y ago
  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.

deleted 5y ago

[deleted]

ricardobeat 5y ago

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.

mst 5y ago
Hrm. "React as Schelling Point" ?

jimmont 5y ago

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?

JoeyJoJoJr 5y ago
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.
- jimmont 5y ago
  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.
- spankalee 5y ago
  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.
  - 5y ago

deleted 5y ago

[deleted]

mst 5y ago

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)