What's New in React 18?
yagmurcetintas.com
yagmurcetintas.com
But on the other hand it becomes clear that decent performance with this approach requires all kinds of tricks and each react version adds more and more of these tricks with a steep learning curve. Shame since react started out with a very small, easy to understand API and that is what made it so popular.
That would be the "all kinds of tricks" the OP referred to. Not that going from one to the other is inherently a win, but that to match the capabilities and ergonomics that classes & objects come with out of the box for addressing state-related performance improvements & state-related features, with "functional" React, you have to resort to "all kinds of tricks", i.e. write your own version of some of the OO things you need to get the job done semi-cleanly (which is exactly what the React team did with Hooks).
The result, to put it in only slightly unfair terms, is that React has enabled their community to use a really bad and half-baked OO system with bizarre syntax & behavior, all so that no-one has to use the "class" keyword sometimes. They didn't do that for funzies, but because some of the things they wanted to do, including things related to performance, required OO-like features to be workable, but for whatever reason they didn't want to rely on built-in language features for that, nor tell their community that sometimes they would have to use those built-in language features. Instead they opted for... Hooks.
Now I'm not at all saying that class components are better. Hooks are mostly easier to work with. But there's no doubt that function components has me using too much brain power and lines of code on memoization. I like the new features the react team are working on, but I hope they'll eventually do something about the stable function reference problem as well.
I don't have the slightest doubts about me being in the minority here, but i've seen a large amount of projects which attempt to use multiple state hooks per component, and as a consequence the dependency arrays become brittle as the code is changed and sooner or later you're stuck with your page being in an endless rendering loop, because your logic isn't clever enough to actually untangle all of the state to decide when it needs to change anything:
useEffect(() => {
... // a whole bunch of code
}, [foo, bar]);
useEffect(() => {
... // a whole bunch of code
}, [bar, baz]);
useEffect(() => {
... // a whole bunch of code
}, [foo, bar, baz]);
You could easily comment that code out or change it. But with hooks, you need to untangle how all of the related calls to setState work and where every method for every state hook is called and why. I'm not sure that it was a good idea to decouple those.
I pretty much stopped paying attention to new versions after React 14.
KISS - keep it stupid simple.
I suspect that some Devs new to JS didn't like the various definitions of "this", and Hooks was supposed to help them out.
No, stale closures caused by hooks are more confusing than what "this" has ever been, especially since this-related problems are mitigated with fat arrows and class property assignment. No, as far as I understand, the driving force behind the hooks was the vision of the coming concurrent mode, for which class components posed some difficult problems somehow.
I fully expect that in a few years React will be widely seen as a J2EE-like poster child of over-engineering shark jumping for the functional paradigm. I already do.
But, I've had way more annoying problems using class-based syntax. Twice the code, four times the pain. And TS type inference doesn't work as nicely with classes.
Vue got it right in many ways. At least back in the 2.0 days, the last I've worked with it.
They’re confusing. The magic is too high. They maintain state in an invisible way. The abstractions are hard to follow, especially when you roll your own.
The key issue for me is that they hide the rendering lifecycle from you. Everything’s implied. One of the complaints with classes was that you had to learn the arcane weirdness of the lifecycle. But a) it’s not that weird and b) it’s much easier to learn when the callbacks are named after the stage in the lifecycle. The hooks way makes all that invisible.
That said, I’m quite fond of the ‘[value, setter]’ return type from useState. It’s nice to use and nice to write. Just don’t ask me to explain how it works for multiple re renders.
I mean, something simple like:
let i = 0;
const inc = () => i+=1;
const [i, setI] = useState(0);
const inc = useCallback(() => setI(currentI => currentI + 1));
For all the hate angularJS got, at least with dirty checking your javascript was just plain javascript. I'm leaning more and more towards svelte, which offers this, but more performant than with dirty checking.
This might actually even have a bug and would need to be even longer to properly function :-D
I think you need to add [i] as a dependency, no?
Now, there are obviously bad ways to use (no pun intended) any tool. Doing things right requires some planning, and learning some patterns. Many effects that also potentially relate to each other should be encapsulated into custom hooks, for example. And it's often a mistake to just make everything hook-dependant—think about how would a non-react bit of the page interact with this feature, or how can you unit-test without dealing with state and component lifecycles.
Learning how to do this in a way that is approachable, maintainable and that closely follows the domain model is not necessarily easy, but that is true for almost every aspect of software engineering, including how to organize functions or classes.
The same is true for things like Suspense. Again, if you have worked on a large application, you'll see that managing side-effects, data that comes (partially or fully) from a backend, and providing a clean and performant experience (no cascading, reasonable errors) is hard. Suspense answers to a real need. Whether you like the solution they propose or not, that there's throwing of Promises involved is, honestly, an implementation detail—and I'd say it works great.
And if these features are not for you, don't use them. And if React is not for you, don't use it. If you have to work on a codebase that is not well architected, full of tangled useEffects, you'd probably have a similarly bad experience if the application was class-component-based or built using a different framework.
Feels like we need a new language with lazy evaluation and a smart compiler that handles this for you for this paradigm to really shine.
I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state (i.e. magic). The best way I can describe it is a cousin of dynamic scoping from the bad old LISP days. Back before lexical scoping was invented. So you end up with all these caveats and gotchas. Go look up useRef with useEffect and useCallback. It's all a total clusterfuck.
The lifecycle methods weren't perfect. But at least you could understand them. But I lost a lot of respect for React way back when they started fussing with the lifecycle API, a year or two before hooks. Their vDOM abstraction was starting to leak heavily and they were struggling to make sense of it.
When people say they like React, I really suspect they mean they like JSX. React, itself, is a mess. Always has been.
The word you’re looking for is side effect. The `use*` family of functions operate as hooks from the component into the renderer, so the renderer can easily see what dependencies a component has. This is accomplished by producing side effects.
The lifecycle methods are all well and good but there was an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function by hand when it involves whitelisting all props you want to produce a rerender, which is most of them. People would always write bugs. It’s much easier to create a list of dependencies a la second argument to useEffect.
Even easier to just not do that, either, as in Solid’s version of hooks.
They've been calling them functional components forever. https://github.com/facebook/react/blob/main/packages/react/i... I'm not sure why you're being a language nazi here. It's beside the points I was making anyway.
> The word you’re looking for is side effect.
Enough with your patronizing. Obviously it is using side-effects. That's the entire point I was making. Functions (as in the term from "functional programming") do not produce side-effects. Functions do not contain state. You know what is good at containing state? Objects. The whole paradigm of an "object" is exactly what React is trying to do with functions. It's nonsense. You can't call a hook function outside of React's apparatus. When React calls one of these hook functions, it has to dynamically switch out the context. Which is where my analogy to dynamic scoping comes from.
> an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function
Yes, well, as I said React has always been a mess and there are just as many problems with useEffect. Throwing out the entire API is just dumb. Libraries are no longer universal. You have to consider whether it's using hooks or not. Especially since they never formally deprecated lifecycle methods. They just shrugged their shoulders and went "here's hooks, use them if you like them."
> Functions (as in the term from "functional programming") do not produce side-effects.
This isn't true, even in the so-called "functional languages." Calling a function in Clojure could produce side effects, and the same is true in Haskell. In Haskell, calling a function that produces a side effect would necessarily return an IO monad, but that's a separate concern from whether the function invocation caused the side effect.
> Libraries are no longer universal. You have to consider whether it's using hooks or not.
You almost never have to think about this. Either a library provides hooks or it provides components. If it provides components, they could be implemented using the old component-style API or using function components; I have no idea, and it's irrelevant unless I plan to fork the library. Conversely if the library provides only a hook, I can easily wrap it in a thin component layer if that's the interface I prefer. The libraries are therefore effectively universal, since there's nothing that says I can't use a hook-based component within a function component, or vice-versa.
State and React have always been fundamentally intertwined, so I'm going to heavily disagree with the claim that hooks are a new magic wrt React. Personally, as someone who has used React for a long time, hooks have been a very intuitive and terse new syntax to use the lifecycle hooks & provides a far superior way to deal with state machine transitions.
> Go look up useRef with useEffect and useCallback
I must say, as a pro web developer who has built loads of applications, including model editors, charts with React views on top of D3 math, interactive 3D renderings, graphs, you name it, I don't know why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. What use case are you trying to solve that requires those hooks and what issue with those hooks exists that is blocking you?
> I really suspect they mean they like JSX. React, itself, is a mess. Always has been
Oh, you just hated React all along, so you probably never understood it. Easy to see why you don't like it then.
The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before.
> Oh, you just hated React all along, so you probably never understood it.
Sure, asshole. I've only been using React for 6 years now. But whatever.
I find hooks provide a far more declarative, testable, predictable developer experience. The simplicity of useEffect, useCallback, useRef, etc. makes it so I know exactly what I need to reach for when I need to accomplish certain things.
It can get complex, but I find that usually means you need to back off and rethink things.
React is one of the thicker layers I've seen.
Really, you're kidding yourself if you think React isn't far simpler than Angular or Vue or any of these other frameworks. If you have some different direction in mind, fine, but I doubt it scales
I would call React thin because the JSX components you build are transparently just objects, they interact with types super gracefully because components are just classes with a method that returns nested objects, and your code is just invoking JS and producing JS until the React library itself performs the side effect of rendering.
I understand that React has abstractions and a heavy scheduling engine and all sorts of complexity, but a React component - the core concept of React - reuses directly JS concepts in place of introducing its own in most situations. That is thin.
I admit that if you are just thinking of libraries in general, of course a frontend framework is not "thin", but for a library which enables true composability and reuse, React is so thin compared to is competitors. Which seems a reasonable de facto context for a conversation about React.
I've run into state/props mismatches due to the diff resolving differently than I thought it should. It's possible to solve this, but it further breaks the illusion of a thin layer.
Maybe it's a different way of thinking, but I don't think two-way binding is inherently thicker. To me, thickness is related to the amount of "mechanism". A handlebars-type templating system seems much thinner to me.
I agree that the tooling and even React itself, under the hood, have never been thin, or if they ever were it was only very early on in the project. Well-functioning enough that one could forget about them at times, maybe, but not thin.
Stateless components are a good idea, but their implementation as functions and hooks leaves any JS programmer not familiar with React scratching their head. Throwing Promises for Suspense is basically Algebraic Effects. Redux and a million other libraries tried to solve data management, none of them doing it in a classical K/V store. Now every app I touch I have to find its special version of reducers and selectors.
I like front end programming and Javascript overall. Components are a nice abstraction, and life cycle hooks make sense in real life contexts. But React reeks of developers who think they are too smart for their day job and want to redefine UI programming just to render a button with an event handler.
Given requirements that meant, to progress, they were going to need to either:
1) Tell devs that sometimes they would simply have to use classes/objects for some components, because certain performance enhancements or state-management would only be available there, or;
2) Partially re-implement objects with really bizarre declaration syntax, in a language that already has objects—shit, its functions are objects, and maybe it's changed but I read the hooks code when it was added and it was just some FIFO property/method queues, rather than tables, tied to a damn object representing your component in React's core state-machine;
They chose #2.
[EDIT] yes I'm aware that one reason they prominently gave for hooks was that inheritance hierarchies could cause problems in React codebases, but that seems woefully insufficient as a motivation for writing a crippled version of objects/classes that lack the features they had problems with, rather than just telling people "maybe stop hitting yourself?" and continuing to use what the language already provided, which everyone already understood.
All UIs need state. Yes state is bad in most cases and makes programming harder. No abstracting it into 4 different files doesn't make it any clearer.
There was an issue with composition in React. HOC didn't scale very well, and Inheritance is almost always Bad (TM). That said, I do think hooks were an esoteric choice versus a more explicit service registration/DI pattern.
Except it is not really functional. See:
https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
The whole thing has been functional programming from the start, if you know what algebraic effects are then the functional underpinning should be obvious to you as well as anyone with the slightest brush with FP. Hell, the original React prototype was in Standard ML, later ported to OCaml and then JavaScript.
> Throwing Promises for Suspense is basically Algebraic Effects
The fact that you disregard Suspense as a head-scratching algebraic effect, instead of using simple "Promises" goes to show how much the JavaScript ecosystem seems to be about fooling people into doing functional programming without triggering their gut reaction of "FP is spooky unproven thing, but Node enterprise ready!".
Imagine for a second that a Promise's .then is called .bind, put it in a thunk if you want to be extra precise and tell me what it is. Hint: It starts with "M" and it's just a monoid in the category of endofunctors.
That's a lot of hot air. There is nothing functional about React. Algebraic effects represent impure behavior in a functional programming language, such as input and output, exceptions, nondeterminism etc. all treated in a generic way. Impure behavior, including algebraic effects, is best avoided in functional programming.
Sorry to post the link again, but please read this: https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
I read the article FWIW, it didn't particularly convince me. I think even writing things in the style of functional programming, if that's what we want to call it, still makes it easier to reason about the code. Confining side effects to hooks also means there's only one place we have to reason about having non pure consequences.
let add (x: int) (y: int) : int =
print_string (Format.sprintf "x: %d, y: %d" x y);
x + y
If you don't have a pure core then you are not using FP.
No, they don't really. Haskell programmers tend to program like that because monads are annoying to use everywhere in your application. But this is really just the hexagonal pattern in different clothes. DDD programmers care a lot about business logic, so the core is business logic. People that like pure functional programming care a lot about pure functions, so the core is pure functions. Some people even mix both (a good example of that is Doman Modeling Made Functional, the talk or the book). I guess people that care a lot about performance would put performance at the center, at the cost of purity and/or abstraction. Basically this whole pattern is a way to ask yourself "What are my values? What's my priority when I develop software?", and to make sure that it's at the litteral center of your application.
So again, you are mixing functional programming, "functional programmers" (which I don't think means anything), and people that value pure functional programming a lot.
Which brings us back to react. Is React functional? What does it means, to be functional? I can at least try see what people mean when they say "React is functional". There are probably multiple things: 1) React is more functional than its predecessors. 2) React share values with functional programming. These are a bit fuzzy, but we can try to answer them.
1) React is more functional than its predecessors: It's surely more functional than traditional vanilla JS, jQuery and Angular. I know that before React Backbone was popular, but I don't know anything about it, so maybe Backbone is even more functional than React, which would undermine this point. I may also have forgot some important development along the way (Ember ? Meteor? CoffeeScript? I wasn't into programming at that time so it's hard to judge the popularity/influence of everything). From what I know, I'd say it's a yes. At least in the most popular frameworks (Angular, React, Vue), React is the most functional.
2) React share values with functional programming. On the frontpage of React, we can see "Declarative: React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes. Declarative views make your code more predictable and easier to debug.". That sounds a lot like what you can hear for some functional programming advocates. "Make the code declarative, be more productive, and the compiler will take care of the performance", in a way. Then there is "Component-Based: Build encapsulated components that manage their own state, then compose them to make complex UIs. Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state out of the DOM.". Making a complex UI by composing simple parts again sounds like composing functions in functional programming. "Encapsulated components that manage their own state" feels more like OO though. I can also add that the React community uses Redux a lot, which was inspired by Elm, which itself is clearly functional programming. I've heard that hooks are a way to get closer to functional programming, but I can't confirm this, as I haven't used them. As a conclusion, I'd say that yes, React share values with functional programming, though it doesn't strive for purity (in both senses of the word).
So, again, is React functional? Yes, I'd say it is. What does it mean to be functional? I think a good example here would be OCaml. OCaml is a functional programming language. OCaml also allows you to do imperative programming, or object-oriented programming. However, in the wild, most of the OCaml code you find is functional. How functional? That depends. For some people it will mean functions and data structures. For some it will be this with modules. For others, that will be monads. So in general, maybe a bit less functional than Haskell, but more functional than Python or Java. That's the same with React. When we say "React is functional", we mean "probably a bit less functional than Elm, but more functional than Angular and Vue".
You're using "functional" in a very specific way, which is usually covered by "pure" or "purely functional", which is unproductive to these kind of conversations.
What is the benefit of being functional?
If there is no benefit then this whole discussion is moot. If there is a benefit to FP that isn't easily achievable using other styles, then does React achieve that benefit by doing FP style?
Or is React leaning on the cachet of FP for marketing purposes?
For React, the idea is building the UI as a function of the state. The benefit is to make the code easier to understand, debug, test, etc. I don't think I have to discuss with your the benefits of pure functions.
> If there is a benefit to FP that isn't easily achievable using other styles, then does React achieve that benefit by doing FP style?
I think it does, partially. Though it isn't going as far as something like Elm.
> Or is React leaning on the cachet of FP for marketing purposes?
I would almost say the opposite, React succeeded at first because it didn't push too much the functional stuff. Elm went farther, and doesn't have the market share of React, because insisting too much on FP, especially at that time, would only scare away developers. If you start to go the FP path, at some point you realize that using JavaScript can't work, and you have to switch to something new. People have experience and huge codebases, so they don't want to switch. You can see the same with TypeScript. TypeScript succeeded because it embraced JavaScript, especially its flaws. That means that as standalone language, TypeScript isn't as good as it could be. But as an incremental improvement in the JavaScript ecosystem, it's good, very good.
To see what happens when you use FP for marketing purpose, you can take a look at ReScript, the current reincarnation of ReasonML.
> For React, the idea is building the UI as a function of the state
Well, if you have state you're already not functional.
Look, React does not have to be functional to be useful! Let's not misappropriate the FP label and apply it to a tech that is clearly not functional, misleading a whole generation of developers.
React is great, hooks are OK, but FP it is not!!
That's just wrong. State will exist, wether you like it or not, and you'll have to deal with it.
Again, you're using FP to say pure FP. Is Standard ML not functional according to you?
Yes, state will exist... in a thin outer layer. Pure core with a thin impure outer layer. If state is distributed throughout the entire program then it is not FP.
Reason has always felt weird and half-baked. It had all that nice syntactic sugar for the benefit of javascript developers — but in the middle of it, there was some OCaml ugliness, like different math operators for integers and floats, or special treatment of recursive functions. Plus a half-baked async story, or lack of unicode support. It was all very weird.
But in other areas: I understand Swift was a great marketing success, and it is heavily influenced by FP, right (I haven't used it personally, so don't know). And so was Kotlin?
From my limited exprience in Swift, it does have functional parts, although I don't know if that's the main focus of the language, or just a nice thing to have.
Kotlin seems a bit more functional than Java, although Java has been catching up recently (sealed classes, pattern matching, record).
This is unhelpful. I don’t know if I’ve ever encountered this attitude before, I’m enthusiastic about FP and I frequently direct people toward FP principles wherever I possibly can. Dissuading application of those principles in part because they’re not applied in (your view of) full is sending people in the wrong direction.
And you might not care, but I do: it’s also gatekeeping. Making people feel like what they’ve learned to make their code more functional, less side-effecting, and generally easier to reason about… making them feel like that’s not important progress they can value unless they share your knowledge and understanding of Category Theory or whatever is going to drive people away from what you want. And it’s going to drive marginalized people away most, probably from programming in general. That stinks.
The level of purity you’re demanding isn’t even claimed by most functional languages. And the ones which do use Monads as a sleight of hand to make the claim, but that’s plainly a useful fiction.
> This is unhelpful.
You have to care about purity. The benefits of FP hinges on this. Saying you don't care about purity is the same as saying you don't care about FP.
That doesn't mean that anything less than "perfect purity" is worthless. You have to always aim for purity, even if you don't always achieve it, because without it there is no FP.
This is more helpful. I’m not going to add my own unhelpful reaction to the rest of what you said, I think I already added more value above than I’m inclined to now.
If that's your definition, functional programs basically don't exist in the real world. Wikipedia (and I) don't agree with that [1], it specifically separates out pure FP [2].
[1] https://en.wikipedia.org/wiki/Functional_programming [2] https://en.wikipedia.org/wiki/Purely_functional_programming
The whole concept of React is to model the UI as a function of the state. React was first made in Standard ML (you don't really get more functional than this). Jordan Walke, the creator, went on to work on ReasonML, an hybrid between the OCaml and JavaScript ecosystems, to try to leverage the functional parts of OCaml.
> Impure behavior, including algebraic effects, is best avoided in functional programming.
This is wrong though. Functional programming doesn't shy away from impurity. Algebraic effects are a way to handle impurity, which is unavoidable.
Disagree. Functional programmers often speak of implementing programs with a pure core and a thin layer on the outside that handles effects. If you don't have a pure core then you are not using FP.
In FP as an umbrella, purity is not a hard requirement for the entire paradigm, only a predominantly pipeline oriented style based around expressions is (in contrast to, say, C, where one generally passes a pointer to the same state around to procedures that pick and choose what to modify in that state bag, as a series of statements). Common Lisp and OCaml are often cited as examples of functional languages that don't attempt to enforce purity guarantees even in terms of idiomatic usage, let alone at a compiler-enforced level.
Using higher order functions for, say, promises (remember, they're stateful!) doesn't mean you're not using functional programming, just like using Array.prototype.map doesn't mean you're not using OOP (it implements fluent interfaces, if you haven't noticed). It's the absence of functional tools/techniques that qualifies a program as not functional.
IMHO, the unfortunate situation is that most JS people don't understand there are different degrees of functional-ness and certain guarantees only exist within specific subsets (and React doesn't conform to that subset).
There are 3 benefits, mainly: (1) Ease of verification, (2) Parallelism and (3) Data-centric computation. (See article I linked for details.)
Of these, Parallelism doesn't work in JavaScript. Since JavaScript doesn't support lazy evaluation, data-centric computation doesn't work that well either. That leaves us with the first benefit alone. But ease of verification is reliant on pure functions. If functions aren't pure then it is just regular code that isn't necessarily easy or hard to verify.
React uses FP for a 4th benefit you won't find in any textbooks on FP: Marketing.
No offense, but your argument is kinda self-defeating if you are trying to claim that two out of the three purported benefits aren't even applicable (and I'd argue that even that first so called benefit doesn't have a great story in JS either).
Saying that verifiability is somehow intrinsically related to purity is IMHO making an overly broad generalization. You're starting from the premise that unit testing a pure function is easy, but that doesn't really generalize in any direction. Array.prototype.splice is not pure and yet it's trivially easy to test. Reasoning about the crashing potential of JS tail recursion is not easy even with purity guarantees. Large functional point-free compositions in JS have impenetrable stack traces. Valgrind et al exist so clearly it's possible to reason extensively about messy stateful things.
Different paradigms aren't oil-and-water and they don't have a monopoly on any given benefit, it's perfectly possible to mix and match features of various paradigms to achieve expressiveness, idiomaticness, predictability, etc.
[0] https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
With reference to the article, it builds on top of authoritative articles (see References section at the bottom), so you don't have to take anything at face value!
You're right, I am indeed saying that verifiability is intrinsically related to purity. The concept of pure functions is at the core of FP. You take that core away and you no longer have the right to call your code FP.
Why is it important to label something as FP in any case? React is useful even if it is not functional. What I am opposed to is misappropriating the "FP" label for marketing purposes, by the React team.
Only in the subset that you consider canon, not generically for all FP. Wikipedia is quite authoritative, FWIW.
I agree that the React team has made some flat out wrong claims (e.g. incorrectly calling hooks pure at one point), but you're engaging in exactly the same sort of "marketing" you dislike, by biasedly claiming your specific flavor of FP is the "real deal", when in reality there are many different cohorts within the larger FP community that prioritize different things.
If I had to criticize your purity-centric flavor, I'd say it's very reminiscent of the height of the OOP craze, with algebraic terminology elitism being similar to the one surrounding GoF pattern terminology. Also similar are the grandiose theories of maintainability, and the dichotomy between what loudmouths preach and what code in the wild looks like.
People log things from .map callbacks. They don't grok monads. It seems entirely arbitrary to me to deny the functionalness of some code based on some technicality (case in point, do you avoid promises and do you Object.freeze(Object.create(o)) all your objects?)
IMHO, there's no point defending some notion of an FP brand. Looking around this thread, you can see that people already view React's hot take on FP as problematic. Same goes for general perception of the more elitist corners of the FP community.
There is literally an example React component in that article that the author calls "pure and referentially transparent". How can this be if there is "nothing functional about React"?
Bootstrapping pseudo FP styles into a Prototype Language with no types (JS is technically not OO, even `class` is just prototype sugar). Please no.
I really like concepts behind FP. I have tinkered with Haskell and gone through Bartosz Milewski's Category Theory material. That said, its radically different than traditional Procedural or OO coding. It really needs language level support to be useful, and that usually starts with types and the compiler. Open up "FP" libraries in non FP languages, and you often discover its just the same objects as the rest of the language.
That said, immutability is awesome. The concept of creating mutability boundaries and only exposing immutable data to external services and clients solves a whole class of bugs related to "who changed that?"
I think many of us familiar with the FP inspiration for language features like Promise also understand that it’s a Monad. But this is a weird response to a comment about the oddity of throwing a Promise. I may be mistaken, but it seems unusual (in the FP analogue) to return an Either<Future<B>, A>, and even weirder to obfuscate that in a seemingly synchronous interface to trick you into thinking you’re returning A | B.
which actually has nothing to do with functional programming, it's just sloppy programming
This is because this person is one of those clowns who learnt one thing about functional programming and use that in every conversation to deflect criticism without much understanding of the criticism
> Imagine for a second that a Promise's .then is called .bind, put it in a thunk if you want to be extra precise and tell me what it is. Hint: It starts with "M"
I’m really cautious to agree here. We’re talking about something that’s increasingly core to React’s design (you don’t throw Promises yourself, the internal APIs do, and it’s documented that way so other libraries can interop). It’s a weird design but I don’t think I could call it sloppy.
> This is because this person is one of those clowns
This is also unhelpful. I hope we can get better at critiquing without attacking the person, even where we disagree with them.
Instead of comming up with new API they retrofit existing one (the render function) to add continuation passing. They use throwing and promise, neither is for continuation passing.
Somewhere in this thread there is a link to the crankjs article which does the same thing using a generator-based API. It is also weird from a conventional point of view but at least simpler and somewhat more intuitive
> better at critiquing without attacking the person
How would you critique an attitude (pretentiousness and unhelpfulness) without attacking the person? This is a shitty trait and you have it but do not feel offended?
It probably helps to understand why they made that choice. I’m not going to go deep into archeology to do that, the likely reason has been a central of several front page articles recently: color of function.
Generators, like you mentioned, can solve this without infecting the whole stack, but it’s probably breaking for a lot of tooling. Async function components are almost certainly out of the question. They probably carefully considered the options and found this pattern unusual enough and identifiable enough to not break the world.
I don’t like it or agree with it. I think it’s really weird. But I can understand how it could happen.
> How would you critique an attitude (pretentiousness and unhelpfulness) without attacking the person? This is a shitty trait and you have it but do not feel offended?
I don’t understand the question. You’re presupposing personality traits where many other things may be contributing. I struggle to communicate a lot of ways, and one of my biggest challenges is actually having my person dismissed or being afraid that will happen. I hope this discussion has given you enough context that you don’t think I’m a clown, now or in any future interactions. But now I can’t know if you will unless you say so. Even though I’m just engaging with you as sincerely as I can.
This, on a scale of every internet interaction, can prevent people from learning or even contributing. Even if they’re talented or otherwise open to learning and have a lot of unrealized potential.
I wish Dan Abramov hadn't made this analogy[0], they're nothing like algebraic effects. The core idea behind algebraic effects is more similar to something like dependency injection if it was generally possible to "deasync"[1] things in JS, except it leverages dynamic scoping instead of lexical scoping. The Suspense thing is closer to those jokes where the punchline is something along the lines of the programmer saying "have you tried to restart it?"
[0] https://overreacted.io/algebraic-effects-for-the-rest-of-us/
I bet it wasn't Dan who came up with this analogy. My bet is on Sebastian: https://twitter.com/sebmarkbage/status/941214259505119232
Class components are dead simple. A class, a setState method, this.props, this.state, and some lifecycle methods. SO easy for anyone to understand.
Function components with hooks are not. A whole new (and unnecessary) paradigm; some mysterious hooks engine that needed new ESLint rules to be created just so people can keep the weird, delicate balance in place; hooks having their own timing problems, requiring usage of useRef which the React team tries to get people to avoid; etc.
Frontend codebases used to have several layers, with React just being one of the thin ones. Now, nearly the entire frontend codebase is inside React world. I'm not a fan of this direction.
FWIW I've seen it in many projects outside of the react/js world as well
IMO there's been a general drought in books/material on reasoning/thinking about software in general in-favor of the framework/library centric mania we have now which focus on the least interesting aspects of the field -- the cynic in me thinks this is due to how we hire people but there's likely more to it than that
2) "Hey it doesn't work with edge case X, let's graft on more features to cover it"
3) Repeat step #2 a few dozen times
4) The framework is now neither fast nor easy, invent a new one and go to step #1
1. Providing a general signal to reuse the existing DOM node (or subtree, but that’s less useful) without performing any render logic.
2. Allowing components to use built-in suspension semantics (generators, async/await).
The former would have other really useful applications, like partial/selective hydration. The latter is closer to both the language and the original spirit of React, which embraced being close to the language. (Who ever thought “throw a Promise” for meaningful control flow before this?)
That said, it’s pretty clear from what React team has discussed since Suspense was introduced that it’s part of a larger strategy. Specifically: React Server Components. They’re laying the groundwork for that now, in stabilizing Suspense SSR.
I’m more interested in a less sophisticated solution, but it’s pretty clear RSC is both where React is heading and requires a more opinionated foundation like Suspense.
> difficult-to-track-down ways because of how errors are propagated with suspense
I suspect this has more to do with concurrent rendering generally, than with Suspense itself. Debugging concurrency is harder in general. React's simplistic top-down rendering model was successful in part because it was simplistic and top-down.
- - -
All of that may not be justified for your needs! React is positioned for a very specific set of use cases (even if it’s over-used for similar-looking ones). You may find you’re more comfortable in a more simplistic VDOM (and that’s okay!) or a library based on reactivity (if so, and if you’re coming from familiarity with React, I’d suggest giving SolidJS[1] a look; its rendering model is much closer to the DOM).
I’ll also mention that I’ve spent more time with Preact than React, and have found its Suspense implementation much easier to work with and debug.
At this very moment I'm wrestling with a UI where the left side is a list of cartographic datasets, and the right side is a rich OpenLayers preview renderer.
I want the right side to be "low priority" where it tries to render a preview, but is happy to abort or not get done in-time if the user selects a different dataset. At the moment, the processing acquiring and rendering the preview makes the rest of the UI a bit laggy.
I suspect a good bit of my custom code can be replaced with some of this transition stuff.
Picture a canvas that I'm calculating then drawing tens of thousands of elements to before displaying it. Very binnable. Very hard to get right to a point that you can't "feel" the lag when working with the rest of the app.
I also explored web workers but it's currently more hassle than I want to be bothered with.
You could try switching to Preact which has better performance and should be painless.
https://krausest.github.io/js-framework-benchmark/current.ht...
I appreciate the advice but I didn't provide sufficient information for informed responses. It was just a general comment about why I'm excited for React 18 to help better manage concurrency in a number of ways.
Suspense will also be nice because I can eliminate a lot of my own "loading screen" logic.
Ah right. I thought the canvas example was just an example.
Still, a faster framework would be better for high performance use case, no?
Maybe that's the real problem? If at all possible, such intensive tasks should be done in native frameworks, not web technologies. Alternatively, why not simply do less? Pagination, extracting separate sections of the app into separate pages/views and many others are perfectly valid approaches to something like that in my eyes, not just turning to low level optimizations.
To use the words of a commenter in another thread: I didn't provide sufficient information for informed responses. It was just a general comment about why I'm excited for React 18 to help better manage concurrency in a number of ways.
This way the cached elements can be shown until the new tree elements are created and you can just react setState to the new elements and it's instant
Link: https://stackoverflow.com/questions/69071151/why-is-console-...
Custom elements are awesome for small things that don't need to appear in an SSR context (assuming you're using shadow DOMs). No, they don't support composable stylesheets, whatever those even are, but seriously, who really needs them? If what you are doing is complicated enough that the browser's native APIs are too obtuse then yeah go for something like React or Svelte. No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. I'd use uncommon browser and language features if they made sense for a task.
The `<template>` and `<slot>` elements are really dopey and hard to understand. That's where something like React or Svelte comes in. Nobody would use either of those libraries if they didn't have better templating than the browser.
What is the idea behind Web Components? Does anyone have an idea of what they are, should be, and where they are going? They've been around for 10 years now. Google has poured literally millions of dollars into trying to make them happen.
If people still "have the wrong idea about web components", it's a testament to their failure.
> Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing.
Well, no. People who say "don't use web components" are very much aware about the fact that web components:
- at the core are 4 different standards. One of them is already fully deprecated (HTML Imports). The other one already has a deprecated and removed version (Custom Elements v0)
- introduced so many problems by simply existing that Google (primarily Google) has been pumping out literally thousands of pages of new specs just to fix the problems that web components created.
Problems: https://dev.to/richharris/why-i-don-t-use-web-components-2ci... and https://news.ycombinator.com/item?id=28697664. And new specs? Oh, they are introducing their own new problems: https://news.ycombinator.com/item?id=28698563
- have an API that is both too high level and too low level to be usable.
It's too low level and too verbose, so after several years of promoting them as "the be all end all components for the web" the narrative shifted to "it's just an API for library authors, you're not supposed to use them by hand". It's unusable at any significant scale. Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.
It's too high level, so in the 10 years of its existence there are hardly any libs and frameworks that have adopted Web Components as the foundation. And even the new ones tend to skip Web Components. Well, most libs and frameworks can compile to Web Components, and can consume Web Components. But hardly any framework actually uses them as a foundation.
Well, I've linked to the dozens of problems that they introduce, so no wonder.
- "Custom elements are awesome for small things that don't need to appear in an SSR context"
that don't need an SSR context, that don't need a11y, that don't need to split SVGs, that don't need...
Too many "don't needs" for a tech that has seen millions of dollars poured into it, and 10 years of development. After all that it's still "it's awesome for small things". Only for small things.
Meanwhile, w3c has unveiled its own design system here: https://design-system.w3.org It uses SASS and it uses a third-party library to, quote, "enhance a <select> into and accessible auto-complete via JavaScript."
Imagine if millions of dollars and countless man-hours poured into Web Components were instead directed to make CSS better, to enhance the crappy built-in controls etc.? Oh, you'd have a better web, and not an "awesome for small things with dozens of problems".
> No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser.
Ah yes. I remember someone calling jQuery "the disappearing framework". Because its eventual goal is to be fully replaced by browser APIs.
It looks like Web Components' motto is "there's always someone doing stuff better in Javascript, so why bother, let's be crap".
> Nobody would use either of those libraries if they didn't have better templating than the browser.
Nope. People are using them not because of templating alone.
In a way, that's exactly my point. I don't get the need to view the related technologies as "web components". It's a branding error made to look niche features sound like something more than they actually are.
> It's unusable at any significant scale.
It's a fallacy to denigrate anything on the basis of scale, because not everything has to be at "scale". That doesn't have to be the job of web APIs. These tools exist to render things on web pages; they weren't intended to satisfy the needs of Google and their wannabes, as much as Google themselves believe otherwise (in seeing themselves as the arbiters of the web).
> Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.
This seems like speculation. People switch projects to their framework of choice for any number of reasons, many of them not necessarily being objective. Preact is way cooler than custom elements, so of course there will be a bias towards using it no matter how useful or not useful custom elements are.
> Too many "don't needs" for a tech that has seen millions of dollars poured into it, and 10 years of development. After all that it's still "it's awesome for small things". Only for small things.
Again, not necessarily anyone's problem. Lifecycle hooks, templates, and shadow DOMs are missing features in a system where nodes can be inserted dynamically. Are they critical? No. Do they "scale"? Maybe not, but that's really not an argument against them being in existence. Frankly, I don't care if someone mistakenly thought they were a multi-million dollar idea.
> Well, I've linked to the dozens of problems that they introduce, so no wonder.
All of those arguments come from the premise that separate APIs are supposed to form something coherent. For one, I don't know how Chrome-only features are somehow supposed to be the fault of web components.
Custom elements are as inaccessible by default as non-semantic HTML elements. The use of ARIA attributes is pretty common for elements that are not custom.
If SSR is a problem then don't use shadow DOMs. If that's irreconcilable then use React or something that can scope CSS. Otherwise, a custom element can receive a role like anything else no matter what context it's rendered in.
> Nope. People are using them not because of templating alone.
That's not what I said. Templating isn't all that React and Vue do, but it's a make or break feature. Few would care about component lifecycle, reactivity, and other features if they had to verbosely hook into elements using regular JavaScript syntax. In particular, nobody would use Vue and especially Svelte if they had no templating. These "frameworks" are primarily templating libraries. React would have never taken off if there wasn't JSX.
> It looks like Web Components' motto is "there's always someone doing stuff better in Javascript, so why bother, let's be crap".
What exactly is the argument against that? HTML is crap, and for good reason. Browsers could have essentially become something along the lines of Adobe Flash, but instead they chose to be adequate for rendering pages. (some notable exceptions notwithstanding) Likewise, whatever "web components" are supposed to be, they add a few niche features to an existing system. Expecting bureaucratic web consortia to be wanting or able to compete with the likes of React is a path to disappointment.
Scale is "anything beyond the simplest of components".
> That doesn't have to be the job of web APIs. These tools exist to render things on web pages
Yes, that is exactly the job of Web APIs, and they are horrible even at rendering things on web pages. You'd have to search really far and really wide to find APIs that are as slow and as inefficient at putting pixels on screen like Web APIs.
But even beyond that, web components are a horrendously bad, overly verbose API that is unsuitable for, you guessed it, scale. Write a few of them by hand, and off you are looking for a framework or library.
> > Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.
> This seems like speculation.
It's not speculation, but an overexaggeration. AMP project is pretty tight-lipped on the reasons why, but here's a big one: https://twitter.com/cramforce/status/1181927980467138560
--- start quote ---
The main issue was that handling attribute/children mutation got too complex when implemented manually instead of relying on diffing.
--- end quote ---
This is what I mean when I'm talking about scale.
> Again, not necessarily anyone's problem.
It is, ultimately, the problem of the people who will be using this tech.
> All of those arguments come from the premise that separate APIs are supposed to form something coherent.
No. All those arguments come from the fact that Web Components break all those things, are broken for all those things, and keep breaking a lot of other things despite everything that's poured into them.
And you can't just hand waive and dismiss all concerns with "who cares".
You have your project and someone brings a Web Component into it? Oops, your project can no longer be SSR'ed.
You have your project and someone brings a custom field into it implemented with Shadow DOM? Ooops, suddently your project has an inaccessible field.
And so on, and so on.
> The use of ARIA attributes is pretty common for elements that are not custom.
ARIA attributes do not cross shadow dom boundary. Web Components will break accessibility instantly just by virtue of existing (if they use shadow DOM).
> If SSR is a problem then don't use shadow DOMs.
Ah yes. "You're holding it wrong". That's the problem with web components: they break in so many common scenarios, that any other tech would be laughed out of the room. And yet, here we are, with people valiantly defending them.
> What exactly is the argument against that? HTML is crap, and for good reason.
HTML is crap, so let's add even more crap to it and be content with this crap?
> Likewise, whatever "web components" are supposed to be, they add a few niche features to an existing system.
That's the problem. The only features they add are "some niche features". The cost of developing, supporting and integrating these features has far surpassed any potential usefulness of these features. And their primary use case, still, is "yeah, maybe as some small dumb components if you don't use shadow dom, if you don't care about SSR, if you don't care about <a dozen other things that developers do care about>".
So what exactly is the idea of web component that everyone misunderstands?
Also no browser vendors that flat out refuse to implement parts of the spec (Apple [0]), or block proposals unless implemented in a highly specific way (all, here's one example [1], ugh politics).
[0] https://bugs.webkit.org/show_bug.cgi?id=182671
[1] https://github.com/WICG/webcomponents/issues/587#issuecommen...
But it's the same rationale IIRC why built-in components are not extensible (even if this was one of the original promises): the browser has no way of knowing about the actual behavior of the object, which leads to all kinds of mess inside the engine.
The validity of Apple's reasoning makes it even stranger.
Quite recently Constructible Stylesheets were released in Chrome:
- because lit wanted them
- despite Firefox and Safari being against the state of the spec
- despite Safari clearly stating they are not going to implement the spec, ever (there was a trivially reproducible race condition in the spec)
The entire discussion here: https://github.com/WICG/construct-stylesheets/issues/45#issu...
<template tag="test"><h1>works</h1></template> <test/>
For simple components, especially stateless ones, React works well. When the component needs to manage user interactions it needs state, and then if you need to update props you have to make a new instance of the component, and that point React has failed in its promise.
https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
Where did you hear that? React.Component has both props and state and both seem to work pretty well together, and you definitely don't need to destroy the component by changing the key property just because props changed.
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
That would suck and make React completely unusable, but it isn't true at all. Assuming that there are necessary state/prop interactions to track (sometimes the two arr largely orthogonal, so you don't need this) you might need to add additional state variables to do last value tracking for props, and then do (with useEffect hooks in a function component, for instance) state updates based on prop changes as needed, but you don't need a new instance on prop changes, generally.
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
React works fine with components that don't follow the recommendation, though if you freely mix internal state updates and external updates via props that shouldn't represent instance changes, you can very easily make something unnecessarily difficult to reason about. So the recommended pattern of either doing a fully-controlled or fully-uncontrolled component is a sensible recommendation that makes sense to guide design. But nothing will break and the React cops won't arrest you if you use props driving state, though if you do too much of that whoever had to maintain your code may be upset.
- form participation without javascript hacks (they are called "an API", but it's a hack) https://web.dev/more-capable-form-controls/
- SSR
- splitting SVGs into components https://twitter.com/Rich_Harris/status/1354165883648827401?s...
- not breaking accessibility by default https://twitter.com/sarahmei/status/1198069119897047041?s=20
and a million other things, big and small
ES6 multiline strings? Enhanced for convenience with a library like lit-html?
These are some disadvantages of webcomponents that I can think of.
- Can't register multiple versions of a webcomponent. Let's say you are using "x-dropdown"@2.0.0 which depends on " x-icon"@2.0.0 and "x-menu"@3.0.0 which depends on " x-icon"@1.0.0. Your app will crash because html tags can't have multiple versions ("x-icon" 2.0.0 and 1.0.0). It makes handling big projects a nightmare. And there are name collisions too.
- Not all properties can be serialized into attributes as strings, so you end up just binding properties. Boolean attributes have special are weird when used in the javascript side (an empty string is treated as a boolean)
- The shadow dom can be too restrictive and inflexible. Implementing portals for instance, requires using ugly hacks that depend on your webcomponent framework.
- Some complex webcomponents are not interoperable among different frameworks.
- Static analysis on webcomponents is poor and fragile. Compare declaring types of events in webcomponents, to declaring types of event handlers in react.
Chrome Dev Tools are also, at least in part, built with web components.
It's not web components that were working for them at scale, but Polymer.
They would've probably nebver completed anything with Web Components alone due to how horrendously bad their API is. You can compare Web Components API and Polymer API here: https://twitter.com/dmitriid/status/865518972380237825
It still took them over two years to switch from Custom Elements v0 to Custom Elements v1.