5 ms·
Honestly, why not just use Clojurescript if that's where the inspiration came from? With Clojurescript/re-frame you don't have to think about which of the myria
by cutler 5y ago
Honestly, why not just use Clojurescript if that's where the inspiration came from? With Clojurescript/re-frame you don't have to think about which of the myriad useX inventions apply to your app. Every couple of years React seems to be throwing-out more clutter (hooks, forms) just to get a bit closer to what Clojurescript + re-frame has had for years.
- kgwxd 5y agoI feel the same way, but it could be a really big commitment to choose ClojureScript for a lot of projects. I have my own shop and haven't had an opportunity where I felt comfortable suggesting it, even though we have a few devs that would love to use it.
- napsterbr 5y agoStrong plus one. Not to mention that I often see highly experienced frontend devs writing components that re-render itself on every change, just because it's so easy to make the mistake of unnecessary re-rendering on modern React. Developing with re-frame means you re-render only when data actually changes, with almost zero chance of making accidental re-renders, and no need to spend mental energy on "should I wrap this with useCallback or useEffect?".
- mariusandra 5y agoSomething that comes for free with Redux and its abstractions like Kea (the approach promoted in the linked blog post) is that you mostly avoid the problem of needless re-renders. Each `useSelector` call (and `useValues` call that uses it) triggers a re-render only when the value changed. So unless you have something forcefully re-rendering the root node, only the few relevant sub-sections of the page will re-render. It's not perfect nested-sub-object level precision, but in practice works well enough.
- cutler 5y agoYet more useX to keep in your head. I don't get it with React.
- yakshaving_jgt 5y agoIt’s definitely easier to swap all of them for a simple useElm.
- mariusandra 5y agoIn the approach described in the blog post, you only need two use*: `useValues` and `useAction` to pull in values and actions from the data layer. Nothing else. No local state with `useState`, no `useEffect` or `useRef` or anything else for interacting with your data. So in effect React == two hooks and JSX.
- cutler 5y agoI was thinking more generally where idiomatic React makes use of the whole panoply of use* variants. React is unusable for me because of this. useForm alone has exploded recently into a proliferation of sub-variants then when you add useController into the mix it's game over.
- acemarke 5y agoIt seems like you're talking about the APIs for a specific library (React Hook Form) rather than React in general. Overall, hooks allow libraries to package custom behavior. The `useSelector` hook mentioned above is a React-Redux-specific API that manages subscribing to the store and re-rendering the component when the requested extracted state value changes. So, the "proliferation" you're talking about here is simply libraries and individuals building their own specific logic on top of React's primitives, in the same way that users build specific components on top of React's component primitives.
- cutler 5y agoIsn't React Hook Form ( https://react-hook-form.com/ https://react-hook-form.com/) from the React team?
- pvorb 5y agoBecause you will reduce the number of potential candidates for hiring by one or two orders of magnitude, even if it might be a technically justified choice.
- yepthatsreality 5y agoThis is always touted as a reason but honestly I always spend time teaching the hired new frameworks, JS knowledge, ecosystem knowledge, etc. The world already operates on multiple languages and JS is already an exhausting confusing ecosystem. There’s no reason not to use something because it’s in a different language.
- pvorb 5y agoI've seen developers being productive with our frontend in React in a day. Additionally, this is not only about new staff. Your current team has to learn the new tech as well and many can't or don't want to spend much free time on things like this.
- graftak 5y agoInteresting how you immediately went to free time offerings for some business decision that would benefit the company.
- pvorb 5y agoI'd also not expect it from anyone. But that's typically how new tech gets introduced. Some lead developer tries out something new in their free time and introduces it into a new product. Others don't spend free time on it, so the company pays for teaching everyone on the team. The tech needs to have a real advantage to justify that overhead.
- yepthatsreality 5y agoI’d be willing to bet that Devs could be productive with Clojurescript in a day.
- EastLondonCoder 5y agoClojureScript is great and it'd be my first choice if performance doesn't matter. For me the drawbacks are that bundlesizes tend to be bigger than using js. Profiling is much harder due to the output from the google closure compiler is somewhat opaque. Reasoning about memory allocation and leaks can be quite difficult even in a complex js app, having persistent data structures makes this an order of magnitude more difficult.
- blunte 5y agoWhen some organization gets serious about providing complete ClojureScript education and tutorials, especially covering the setup/config challenges... and then keeps those current so the examples always work, then this could be a reality. But as long as a newbie has to piece together their own solution from many optional libraries and build systems, the initial time investment will dissuade people from taking the plunge. Of course, an established Clojure shop has already gotten over this hump and can easily onboard and bring new devs up to speed. If the Clojure world never realizes they need to get serious about providing quality education, then Clojure will decline in use relative to other options. It's a shame.