171–180 of 298 posts
don’t tell him about SwiftUI
Earlier quoted context omitted.
It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". It really shows the biases of the maintainers (the "just a library" thing being a philosophy I liked from vjeux, and the "language-likeness" being very obviously a heavy influence from sebmarkbage). The thing w/ "language-ness" (as opposed to "library-ness") is that additions and c…
I thought Jordan Walke created React, not Sebastian Markbåge, in which case he already moved on (to ReasonML)
Earlier quoted context omitted.
By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.
For example Angular templates, stuff like Razor in .NET, etc?
If the assertion is just that `var div = document.createElement('div')` is quite similar to `var div = React.createElement('div');` then of course I agree. In this sense, JSX+React is to DOM what XAML+WinForms is to win32. I had assumed we were discussing conceptual leap between native and framework-based UI implementations.
From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application.
Earlier quoted context omitted.
= Foo({ bar: "baz" })
= React.createElement(Foo, { bar: "baz" })
Earlier quoted context omitted.
> Maybe I'm weird, but I never really wrote JS that caused scoping issues, so I never found `this` to be a problem Either you're weird, or you've been doing JS mostly in the modern era of fat arrow functions, and fat arrow functions have succeeded at reducing the confusion from nested functions each with their own `this`.
Even before arrow functions I just never had much trouble. I had a very consistent way of writing logic. Only ran into scoping issues a few times.
I find my older pure JS codebases so, so much easier to go back and remember what was going on than some of the React stuff I've had to interact with in the past 5+ years - and I say this as someone who has written, released, and taught React.
The problem for me is, I think, I'm not sure you can do better than React. You'll either wind up with some complicated beast from hell (Angular) or veer off into performance-benchmark-overvaluing (Svelte).
Hooks elucidate everything I've felt wrong about React, but have not been able to put my finger on it until recently. Hooks reveal two major things with React: 1) React developers did not understand the component paradigm that they originally went with. If they did, then they would understand how silly it is that components cannot reuse logic. This was an entire debate many years ago. Composition vs. inheritance. You…
> But it should suffice to say, FUNCTIONS DO NOT HAVE STATE It's funny you say that: useState is the same model functional languages use to handle mutability. https://docs.racket-lang.org/reference/boxes.html
That definition leads to the conclusion that hooks aren't functions, which seems fine honestly. I mean, why insist on using them as functions when they're clearly not? Their syntax is a bit unfortunate, as is the fact that you're not forced to declare them immediately at the start of your function, which looks like it would have cleared up many of the potential problems. Either way their use case is clear, using hooks seems to basically dynamically declare a state monad for that particular function (hence why I'd recommend doing this upfront).
I'm not a React programmer though, so take this with a grain of salt.
I have some similar gripes. I find Hooks to save a bit of coding overall. I've found my functional components to be about 10-20% smaller than my class components. I'm not 100% convinced it's really worth it, though. With class components, my state/props are clearly defined within the constructor and/or PropTypes. This makes it easy to understand the overall architecture of a component. Functional components with Hook…
What do you mean? PropTypes work just as well with functional components as they do with class components.
Earlier quoted context omitted.
= Foo({ bar: "baz" })
= React.createElement(Foo, { bar: "baz" })