2 ms·
We simply have different boundaries on whats a tool problem vs a developer problem. If the tool is easily misused, the tool is wrong. i.e. "You're holding it w
by nemothekid 1y ago
We simply have different boundaries on whats a tool problem vs a developer problem.
If the tool is easily misused, the tool is wrong. i.e. "You're holding it wrong" is a problem with the phone, not the user.
>The language is sort of settled. The browser runs JS, so for most projects, it's the right choice.
TypeScript exists. Something could be made that compiles to JS that makes this easier.
- schwartzworld 1y agoI've been using Typescript for years and while I love it, it's far from the magic bullet. No, you'd need something more opinionated and actually typesafe, and now you're writing a different language that compiles to JS. There's a bunch of these, and they haven't caught on for a reason. Eventually you're going to need JavaScript. There are more opinionated UI frameworks (angular) and frameworks with less magic baked into them (svelte, solid). React gives you the freedom to architect your app the way you want, for better or for worse. It was made by functional programmers to allow them to use composition and other FP paradigms in UI development. If you don't understand those concepts, or you just don't care for them, you're going to be swimming against the tide. Lots of tooling has been created to help those who do (Redux, for example). Maybe you're right and "you're holding it wrong" isn't a valid answer, but it's not React's fault it took over the world. It was made to do a certain thing, and it's pretty good for that. That thing requires a way to create side effects (useEffect) and a way to provide referential stability (useMemo, useCallback). The React team has done a lot to document the right way to use these tools. If it's not someone's thing, that's cool. If they are forced to use it at work, might as well learn a little FP and make life simpler.