3 ms·

I think we should find a balance between on using frameworks. Here's my experience with mobile, but the same idea applies: In my early years (circa 2015) I did

I think we should find a balance between on using frameworks. Here's my experience with mobile, but the same idea applies: In my early years (circa 2015) I didn't know much about patterns and wrote this "super smart" code where I called all the API calls yet never used the results directly, passes all the responses through a pipeline, wrote them into a flat normalized state, then fired change events, and my views actually listened to change events and reacted to them to update the UI with a single-source-of-truth local store in both Objective-C and Java for our iOS and Android apps. (There were other "weird" things that "I invented" but this was the relevant part) Sounds familiar? Then, years later, I learned about React Native and redux, and saga, which (albeit with a completely different language and syntax) roughly worked the same way I envisioned and wrote my app (which worked flawless and bug-free by the way, a validation of the pattern works). Now, I use React Native (which also came as a bonus because when I learned it I also have automatically learned its web-counterpart React.js as well) which has the same "vision" in terms of store and observing/reactiveness. Now I use React [Native] because it gets my work easier, faster, and is super popular. I know it will probably not be super popular in, say, 15 years, but the ideas and patterns (reactive programming, state/reducers etc) will be here, and I can adapt to $(popular-reactive-framework-with-nice-syntax-of-year-2035) because that will be making my job easier. (Assuming that I'll still be doing mobile/web development) I think as long as we want to get the general philosophy of these frameworks and know how to implement the parts needed from scratch if we ever need to, they do more good than harm.

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).

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).