3 ms·

Your technical comments make sense. But regardless of the underlying tech, React has enabled an entire generation of devs to create front end apps with solid c

Your technical comments make sense. But regardless of the underlying tech, React has enabled an entire generation of devs to create front end apps with solid community support. For most use cases, React is great. Performance is good, documentation is robust, community is supportive, online videos, books, tutorials etc. are plenty. These things also matter. Some of the technically most unsound languages, frameworks etc. have very high adoption for these reasons. So no, I don't agree that React sounds ridiculous from a holistic perspective.

noduerme 5y ago
>> Some of the technically most unsound languages, frameworks etc. have very high adoption for these reasons This is actually it. This is what pisses me off, and has been slowly pissing me off for about 20 years. I didn't mind closed source, bullet in a box VMs in the browser. They were good at what they did. Now we have these technically shoddy paradigms that take over, because they're easy enough for children to understand, and because they technically conform to open standards. But in fact they're a complete and gleeful obliteration of standards and practices, promoted by one FAANG or another, to try to corner the market and force technical debt on everyone else. You wrote a million lines of interface code in JSX? Good luck rewriting that. It doesn't take a genius to roll your own, and yet, for lack of talent of foresight or intellectual rigor, you have even small, experimental startups shunning building better technologies, in favor of these ridiculous backwards constructs. There is nothing about an observation pattern / MV without control / virtual DOM that is special. Why would anyone want Facebook's flavor of illegible jargon as the foundational technology for their startup's front-end? If it's because that's what newbie coders know, and that's the only way for companies to hire newbies, it would actually be building a technical moat to spend an extra few months and build a technology that wasn't reliant on a framework controlled by FB.
- briznad 5y ago
  My company is currently porting a critical app to React, yet I feel similar to you on most of your points. The app in question is currently using Angular 9, so a fairly similar beast. But React, by comparison, is worse in most ways IMO. The ugly syntax forced by JSX, the combination of template and logic together in 1 file, the odd forcing of certain unintuitive abstraction patterns while also claiming to be "not opinionated" about other crucial aspects of how an app works, and I certainly agree it is not special. However, your argument starts to erode for me when you claim you'd rather spend a few months to build your own moat. You're not just choosing to incur that cost once when you build it. You're incurring a multi-month charge of developer cost that doesn't result in anything being produced for every dev you add to the team, as they have to learn the ins and outs of your proprietary abstraction without the aid of any documentation (assuming) or community to help when they get stuck. This also means a large part of your time is now spent reactively answering pings for special case questions and "what does this opaque error mean" and "how come this thing doesn't work when I do that thing"? And good luck hiring devs who are excited to work on your special creation, not to mention how you have to adapt your hiring process to determine who will be likely to succeed in such an environment. That sounds like a lot of stress to place on a fledgling company trying to grow at a crucial stage and could certainly be a contributing factor in your post-mortem when things don't work out. By contrast, by advertising for React vs Angular devs we can expand our candidate pool 5-10x and anticipate reduced ramp up time and increased velocity out of the gate. And since hiring and growing my team is one of the most expensive and difficult things I'm grappling with, that's what I'm optimizing for. In the battle between pragmatism and idealism, pragmatism wins the day once again.
  - noduerme 5y ago
    You make some valid points. I think my issue as a solo, freelance dev is that keeping up with the latest flavors of trending frameworks, and all the attendant updates to them, drains my time and ability to solve real problems. It's not that I sit and write a new MVC pattern every time I build an app. I iterate on what's already in my toolkit, that's been built over a couple decades. Once in a long while that means refactoring or rewriting completely in a different language; I recently ported and cleaned a huge amount of my PHP boilerplate to Nodejs. One issue is that I get paid to write, and I don't want to be stuck in updates and maintenance whenever the team behind a framework announces a ton of breaking changes in the next version, and things become EOL. Bad enough when it happens with languages and databases. Those teams have an incentive to do that, to stay relevant. I need to expect a framework to remain roughly stable for a decade or so, or I'll be forever rewriting a small set of apps. Moreover, my clients expect to have software that runs for 10+ years without needing a full overhaul. Whatever time might be saved at the beginning by using something like React (and I'm not convinced it's that much time) would probably be lost later in keeping up with the changes. One thing that does cause trouble is having to call a client and say, sorry but some part of our stack is EOL and we need to rewrite it by next year. I don't want to write it and they don't want to hear it. An example of a hole I got myself into was using Bootstrap v4 alpha when I moved most of my UI out of Air and into JS. At this point I have to just accept that some apps will never get an upgrade to a later version of Bootstrap. But it's not critical... it's just a bunch of CSS and there's no reason you can't use v4a forever if it works for your purposes. I used to build business apps in AS3/Air. 10 years on, some are still in the wild and I have to explain that, look, I didn't predict the death of this language but eventually your app is going to need a rewrite, because I can't even compile it without pulling out an old laptop. And this is where maintaining an in-house framework comes in useful, because I've slowly ported most of my Air components and their functionality into JS. So the rewrite will take less than half the time as the original. Anyway, I do understand your viewpoint when it comes to hiring and growing a project quickly through a critical phase. Particularly if you're coding for one company and you can afford to switch platforms next year if you succeed. I think it calls for a different approach than what might be good for a solo coder working on in-house employee apps that have to just be stable over long timeframes. Thanks for the comments.

noduerme 5y ago

>> Some of the technically most unsound languages, frameworks etc. have very high adoption for these reasons This is actually it. This is what pisses me off, and has been slowly pissing me off for about 20 years. I didn't mind closed source, bullet in a box VMs in the browser. They were good at what they did. Now we have these technically shoddy paradigms that take over, because they're easy enough for children to understand, and because they technically conform to open standards. But in fact they're a complete and gleeful obliteration of standards and practices, promoted by one FAANG or another, to try to corner the market and force technical debt on everyone else. You wrote a million lines of interface code in JSX? Good luck rewriting that. It doesn't take a genius to roll your own, and yet, for lack of talent of foresight or intellectual rigor, you have even small, experimental startups shunning building better technologies, in favor of these ridiculous backwards constructs. There is nothing about an observation pattern / MV without control / virtual DOM that is special. Why would anyone want Facebook's flavor of illegible jargon as the foundational technology for their startup's front-end? If it's because that's what newbie coders know, and that's the only way for companies to hire newbies, it would actually be building a technical moat to spend an extra few months and build a technology that wasn't reliant on a framework controlled by FB.

briznad 5y ago
My company is currently porting a critical app to React, yet I feel similar to you on most of your points. The app in question is currently using Angular 9, so a fairly similar beast. But React, by comparison, is worse in most ways IMO. The ugly syntax forced by JSX, the combination of template and logic together in 1 file, the odd forcing of certain unintuitive abstraction patterns while also claiming to be "not opinionated" about other crucial aspects of how an app works, and I certainly agree it is not special. However, your argument starts to erode for me when you claim you'd rather spend a few months to build your own moat. You're not just choosing to incur that cost once when you build it. You're incurring a multi-month charge of developer cost that doesn't result in anything being produced for every dev you add to the team, as they have to learn the ins and outs of your proprietary abstraction without the aid of any documentation (assuming) or community to help when they get stuck. This also means a large part of your time is now spent reactively answering pings for special case questions and "what does this opaque error mean" and "how come this thing doesn't work when I do that thing"? And good luck hiring devs who are excited to work on your special creation, not to mention how you have to adapt your hiring process to determine who will be likely to succeed in such an environment. That sounds like a lot of stress to place on a fledgling company trying to grow at a crucial stage and could certainly be a contributing factor in your post-mortem when things don't work out. By contrast, by advertising for React vs Angular devs we can expand our candidate pool 5-10x and anticipate reduced ramp up time and increased velocity out of the gate. And since hiring and growing my team is one of the most expensive and difficult things I'm grappling with, that's what I'm optimizing for. In the battle between pragmatism and idealism, pragmatism wins the day once again.
- noduerme 5y ago
  You make some valid points. I think my issue as a solo, freelance dev is that keeping up with the latest flavors of trending frameworks, and all the attendant updates to them, drains my time and ability to solve real problems. It's not that I sit and write a new MVC pattern every time I build an app. I iterate on what's already in my toolkit, that's been built over a couple decades. Once in a long while that means refactoring or rewriting completely in a different language; I recently ported and cleaned a huge amount of my PHP boilerplate to Nodejs. One issue is that I get paid to write, and I don't want to be stuck in updates and maintenance whenever the team behind a framework announces a ton of breaking changes in the next version, and things become EOL. Bad enough when it happens with languages and databases. Those teams have an incentive to do that, to stay relevant. I need to expect a framework to remain roughly stable for a decade or so, or I'll be forever rewriting a small set of apps. Moreover, my clients expect to have software that runs for 10+ years without needing a full overhaul. Whatever time might be saved at the beginning by using something like React (and I'm not convinced it's that much time) would probably be lost later in keeping up with the changes. One thing that does cause trouble is having to call a client and say, sorry but some part of our stack is EOL and we need to rewrite it by next year. I don't want to write it and they don't want to hear it. An example of a hole I got myself into was using Bootstrap v4 alpha when I moved most of my UI out of Air and into JS. At this point I have to just accept that some apps will never get an upgrade to a later version of Bootstrap. But it's not critical... it's just a bunch of CSS and there's no reason you can't use v4a forever if it works for your purposes. I used to build business apps in AS3/Air. 10 years on, some are still in the wild and I have to explain that, look, I didn't predict the death of this language but eventually your app is going to need a rewrite, because I can't even compile it without pulling out an old laptop. And this is where maintaining an in-house framework comes in useful, because I've slowly ported most of my Air components and their functionality into JS. So the rewrite will take less than half the time as the original. Anyway, I do understand your viewpoint when it comes to hiring and growing a project quickly through a critical phase. Particularly if you're coding for one company and you can afford to switch platforms next year if you succeed. I think it calls for a different approach than what might be good for a solo coder working on in-house employee apps that have to just be stable over long timeframes. Thanks for the comments.