3 ms·

> Now I use React [Native] because it gets my work easier, faster, and is super popular. In what way was it easier and faster than what you had, though? Like,

by saurik 5y ago

> Now I use React [Native] because it gets my work easier, faster, and is super popular. In what way was it easier and faster than what you had, though? Like, you didn't explain that part. My experience is that the systems I develop "stand the test of time" in that even a decade after I develop them I still enjoy working with them, and I "get them" as I built them, myself, from nothing. If they don't do something, it is easy for me to add that functionality, as I know how to extend what I built. Meanwhile, if I discover I did something wrong--and we all do something wrong--I can just fix it, no matter how much skew that might cause, as I am in charge of the entire codebase. However, when I work with other peoples' code, none of this is true. If it doesn't do something I need, I am generally stuck hoping someone else is willing to add the functionality, or I am probably going to just have to do without. Sometimes I can add it myself, but then I am maintaining a fork of someone else's project, and they have no reason to not break what I dis constantly. The other peoples' code of course also has mistakes--as we all make mistakes--but those mistakes tend to never get fixed as they are afraid of breaking other peoples' projects that rely on them: the sheer amount of broken bullshit I put up with to use Flutter is insane. Meanwhile, I used to think that the people who built libraries would at least tackle "the hard parts" such as building world-class security into their frameworks and ensure backwards-compatibility support for as many old platforms and browsers as was feasible. Only, then I became a security expert and discovered that these frameworks are littered with serious systemic issues that they merely "mitigate" and then re-introduce the same kinds of mistakes over and over again. In my projects, once I learn about a class of bug, I go to whatever lengths possible to re-design my APIs to prevent that kind of bug going forward, and I also have then personally "learned" about the class of bug and--because it is just me writing the code--I can even just trust myself to not re-introduce an issue. I have never seen a framework project that cared enough to break all users every time they learned about a new class of issue to truly prevent it going forward, and they have "too many cooks" to trust any of their developers to not keep doing dumb shit over and over again. I also had to learn time and time again that framework developers are in fact the LAZIEST developers I have ever had the misfortune of interacting with, and they will happily drop support for random platforms even when there are non-negligible numbers of people still using them: as a brutal example (but one of many many many) when virtually all of my educational users were bit by a bug in jQuery--which of course isn't even a framework and frankly the ONLY thing it supposedly does is provide a browser abstraction--that crashed (like the whole browser would die) Safari 1.x, and I talked to my friend who worked on jQuery core about it and he told me "no one uses Safari 1.x anymore" even though everyone except me living in my apartment was even still using it, I realized that I should have just kept using my own jQuery-like stuff (which was frankly better anyway: I switched as I figured "jQuery is popular and documented and other people will understand it"... and our big release demo day crashed and burned because of that incorrect mental model). So I just don't get it: why is using React better than what you had? How much effort would it really have taken you to just get your code to the point where you could have avoided React? What is really the goal of running on the framework treadmill to chase "popular" frameworks rather than just building something you trust and using it... potentially for the rest of your life? Because I am now 40, and if I could go back in time and NOT use every framework I ever used, going back to when I was a kid programming (as I have been programming since I was like 6 or 7)--and yet still have all of the jaded and cynical lessons I learned from using it (so I know to avoid them going forward)--I would, as I am sure I'd have managed to build every project that touched one easier and faster.

can16358p 5y ago
It's mostly collaboration-related: I work in several projects with other people. What I have built for my project might indeed be better than React for that particular set of needs, but I'm much more likely to find people who know React (or any other popular framework, React's just an example here) and start working with them, which would be impossible with my custom framework. Actually exactly this happened: even though my code was super-clean (for me, at least) it took me days to show how it worked to a collaborator. In the end he gave up because no matter how I explained him, he wasn't learning it, he was memorizing it (maybe my fault for not being clear, maybe his fault for not focusing enough to understand), and we gave up and because of business constraints I let him go his way, messing up the whole project with spaghetti code. On the other hand I joined a React Native team, and day #1 I was productive, writing actual working code, because we spoke the same language: after a brief one-hour intro to the project by the people who wrote it, I knew the hierarchy, how reducers and actions were organized, queries were dispatched etc. I hear you, and what you do is actually what I personally love doing too. Sometimes I try to reinvent the wheel and that's not necessarily bad: it teaches me A LOT about why some frameworks/libraries are the way they are (just like my own code before I knew about React and how the idea was similar) but if I'm going to collaborate with others I'd still use React or whatever suits as the common denominator of all devs for the sake of throughput and maintainability. It's not that I don't trust my code, it's more that I just have trouble teaching it (or lose a lot of time doing it while I have tight deadline constraints).

by saurik 5y ago

can16358p 5y ago

It's mostly collaboration-related: I work in several projects with other people. What I have built for my project might indeed be better than React for that particular set of needs, but I'm much more likely to find people who know React (or any other popular framework, React's just an example here) and start working with them, which would be impossible with my custom framework. Actually exactly this happened: even though my code was super-clean (for me, at least) it took me days to show how it worked to a collaborator. In the end he gave up because no matter how I explained him, he wasn't learning it, he was memorizing it (maybe my fault for not being clear, maybe his fault for not focusing enough to understand), and we gave up and because of business constraints I let him go his way, messing up the whole project with spaghetti code. On the other hand I joined a React Native team, and day #1 I was productive, writing actual working code, because we spoke the same language: after a brief one-hour intro to the project by the people who wrote it, I knew the hierarchy, how reducers and actions were organized, queries were dispatched etc. I hear you, and what you do is actually what I personally love doing too. Sometimes I try to reinvent the wheel and that's not necessarily bad: it teaches me A LOT about why some frameworks/libraries are the way they are (just like my own code before I knew about React and how the idea was similar) but if I'm going to collaborate with others I'd still use React or whatever suits as the common denominator of all devs for the sake of throughput and maintainability. It's not that I don't trust my code, it's more that I just have trouble teaching it (or lose a lot of time doing it while I have tight deadline constraints).