Earlier quoted context omitted.
Yes, since I spent over 10 years writing it in the first place it was easy to verify!
This is a key piece of information you left out of your original post.
[deleted]
I Don't Like Magic
131–138 of 138 posts
Re: I Don't Like Magic
#132Earlier quoted context omitted.
> Electricity is magic. TCP is magic. Hmm, they aren't if you have a degree. > Browsers are hall-of-mirrors magic More like Chromium with billions LoC of C++ is magic. I think browser shouldn't be that complex.
> I think browser shouldn't be that complex. how is browser formed. how curl get internent
They need to do away instain coders!
Re: I Don't Like Magic
#133React is a weird beast. I've been using it for years. I think I like it? I use it for new projects too, probably somewhat as a matter of familiarity. I'm not entirely convinced it's a great way to code, though. My experience with it is that functional components always grow and end up with a lot of useEffect calls. Those useEffects make components extremely brittle and hard to reason about. Essentially it's very hard…
Re: excessive useEffects, this article from React docs is great: https://react.dev/learn/you-might-not-need-an-effect
Re: unrefactorable, large components, you probably want to break these down into smaller pieces. This talk ("Composition is all you need") is an excellent guide on the topic: https://youtu.be/4KvbVq3Eg5w?si=1esmAtrJthois1uf
Re: performance, people overstate the performance overhead of VDOM. Badly performing React applications are virtually always due to bad implementations. React Scan is an excellent tool for tracking down components that need optimizing: https://react-scan.com/
Re: getting other people on the team to write good code, this is the biggest struggle IMO. Frontend is hard because there's a lot of bad ways to solve a problem, and co-workers will insist that their changes work so why invest more time into building things correctly. I've only found success here by first writing an entire feature with good patterns and pointing to it as reference for other teams. People are more willing to make changes if they find precedent in the codebase.
Re: I Don't Like Magic
#134Earlier quoted context omitted.
The problem with this is that it means you have to read guides which it seems no one wants to do. It drives me nuts. But ya, I hate when people say they don't like "magic." It's not magic, it's programming.
https://medium.com/luminasticity/laborers-craftsmen-and-arti... in my experience among personality types of programmers both laborers and artists are opposed to the reading of guides, I think the laborers due to laziness and the artists due to a high susceptibility to boredom and most guides are not written to the intellectually engaging level of SICP. Craftsmen are naturally the type to read the guide through. Of co…
I don't disagree, but the fact that it's not required to border on expert, or be willing to put in the work to get there, of a framework or library you are going to be working heavily in a pretty broken thing about our industry. But you know, as people have been posting lately: not AI therefore irrelevant.
Re: I Don't Like Magic
#135React is a weird beast. I've been using it for years. I think I like it? I use it for new projects too, probably somewhat as a matter of familiarity. I'm not entirely convinced it's a great way to code, though. My experience with it is that functional components always grow and end up with a lot of useEffect calls. Those useEffects make components extremely brittle and hard to reason about. Essentially it's very hard…
Re: excessive useEffects, this article from React docs is great: https://react.dev/learn/you-might-not-need-an-effect Re: unrefactorable, large components, you probably want to break these down into smaller pieces. This talk ("Composition is all you need") is an excellent guide on the topic: https://youtu.be/4KvbVq3Eg5w?si=1esmAtrJthois1uf Re: performance, people overstate the performance overhead of VDOM. Badly perf…
Definitely good points, thanks for the links. While I try to practice all of these, I think what tends to happen on large codebases is just a bit of entropy. Like, these are all good practices that are either a little obscure or a little less convenient, and so they don't tend to be used. I dunno, it's kind of like in OO code when people just keep letting classes grow. I think the subtle difference though is most IDE's are quite a bit better at refactoring classes than components though. Hopefully that changes. (I know you can use AI for refactoring, but I prefer doing it mechanically.. more predictable and also just not burning tokens)
Re: I Don't Like Magic
#136Re: I Don't Like Magic
#137Earlier quoted context omitted.
This code only works if run in a browser composed of millions of lines of C++.
I felt a great disturbance in the Force, as if millions of React devs cried out in terror and were suddenly silenced.
I love the term "React devs", it comes up on here a lot, and imagines a straw man group who really don't know how to build apps for the browser without React. It exists in tandem with the "frameworks for the web change every week" crowd, creating a vicious farcical enemy simultaneously confronted with a constant cycle of relearning while never being capable of learning at all.
Re: I Don't Like Magic
#138Earlier quoted context omitted.
You can learn JavaScript and code for life. You can’t learn React and code for life. Yeah, JavaScript is an illusion (to be exact, a concept). But it’s the one that we accept as fundamental. People need fundamentals to rely upon.
The only reason why you regard JavaScript as “fundamental” is that it’s built into the browser. Sure, you can draw that line, but at least acknowledge that there’s many places to draw the line. I’d rather make comparative statements, like “JavaScript is more fundamental than React,” which is obviously true. And then we can all just find the level of abstraction that works for us, instead of fighting over what technol…
I agree and I think it’s a nice explanation that fundamentality (characteristics upon which everything depends or would not be possible) is contextual.