React Strikes Me as Ridiculous
10 comments
> Why does every new front-end developer job now ask for React as a core competency?
Simply because the web apps you are going to work on are and will be written in React. There are Vue job postings, Angular job postings, etc.
> Do people think it's going to still be a dominant framework in a few years?
People and organisations that invest in React either think so or don't care. Web apps tend to be rewritten, not maintained anyway, so React is currently a pretty good choice given its ecosystem, its corporate backing, and the sheer number of "React Devs". What about the next iteration? We'll see.
> Is that a framework you would use to build an app?
TBH I don't like React either, or Vue, or Angular. But I have built apps with those and they do the job, regardless of what megacorp is or isn't behind them. Was it enjoyable? No, it didn't feel like programming. Were they necessary? Probably not. Do they have a future? Certainly, as long as front-end developers will so eagerly look for solutions to non-existent problems and reinvent the wheel.
Simply because the web apps you are going to work on are and will be written in React. There are Vue job postings, Angular job postings, etc.
> Do people think it's going to still be a dominant framework in a few years?
People and organisations that invest in React either think so or don't care. Web apps tend to be rewritten, not maintained anyway, so React is currently a pretty good choice given its ecosystem, its corporate backing, and the sheer number of "React Devs". What about the next iteration? We'll see.
> Is that a framework you would use to build an app?
TBH I don't like React either, or Vue, or Angular. But I have built apps with those and they do the job, regardless of what megacorp is or isn't behind them. Was it enjoyable? No, it didn't feel like programming. Were they necessary? Probably not. Do they have a future? Certainly, as long as front-end developers will so eagerly look for solutions to non-existent problems and reinvent the wheel.
I'll admit react is not the ideal technology for frontend but it is also not a bad one especially given the alternatives of designing one's own ui library.
It is in demand not because it's the best technology but because it's well funded, has extensive library support and there's a wealth of tutorials online to learn it. Best technologies often don't win the popularity race.
React is still a very powerful way to create reusable uis but you need to be familiar with its internals and state management.
I personally would prefer writing my uis in something like elm which is far better designed and has some great ideas but in most projects I have to stick with react because everyone knows it.
I think I'm just disheartened that so many people would absorb a "just ok" technology because everyone else is, and then make it a basic attribute of their infrastructure. A few years ago I saw the same thing for Angular but not to the same extent. It just feels like a herd mentality.
People say "oh, it's so much technical debt to rely on a custom UI platform". Really? Compared to something everyone uses, like, uh, JQuery? D3? Angular? Flex? I don't see how rolling your own incurs more technical debt than relying on a framework that may or may not have an ecosystem in a few years... and isn't the best solution anyway.
People say "oh, it's so much technical debt to rely on a custom UI platform". Really? Compared to something everyone uses, like, uh, JQuery? D3? Angular? Flex? I don't see how rolling your own incurs more technical debt than relying on a framework that may or may not have an ecosystem in a few years... and isn't the best solution anyway.
I think you need to understand that most Dev's really cannot make a custom ui platform that will be easy to use and maintainable for the whole team.
An advantage of open source libraries is that you can find people who are already proficient in the code while as for in house libraries you need to train them.
Going in house is perfectly reasonable if it brings a substantial competitive advantage to the business otherwise it's a liability
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.
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.
>> 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.
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.
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.
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.
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.
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.
Hear hear. My take: web components + light tooling like Lit can do 90%+ of what React claims to do and it's way leaner and closer to the HTML/JS specs. I have to work with React sometimes because, well, a man's gotta eat…but I look forward to the day it's no longer the hotness du jour.
The state of the web is far from ideal and there is no end in sight
I've just accepted at this point that the train has been off the rails for a long time and will never reach them again
Web dev is a path I got off of early, and I'm glad I did, despite going to college for it, I would not want to be part of what it has become
I've just accepted at this point that the train has been off the rails for a long time and will never reach them again
Web dev is a path I got off of early, and I'm glad I did, despite going to college for it, I would not want to be part of what it has become
I think the promise of a virtual DOM is fun, but ultimately once you've dispensed with IDs and everything is an object, you still need keys; which means you need to bring back IDs in the model; which means you still have to go back to interacting with the DOM where you started, there's just a further layer of abstraction, one which you can't control the lifecycle of. And a hard-to-read abstraction! Now you can't just check the properties of a tag to see what hooks into it; it's instantiating something beyond your control, on its own.
Why does every new front-end developer job now ask for React as a core competency? Do people think it's going to still be a dominant framework in a few years? I really hope coders are able to think outside this paradigm and create their own element / component hierarchies without relying on this extremely hinky observational system to run the DOM for them. For instance (as an alternative) in big web apps I register components with my own MVC pattern, giving them unique Class.struct.IDs and assign them broad (global), narrow (within a parent component) or specific (just this component) listeners, to cause DOM redraws / updates; and these refreshes can be triggered by setting off events anywhere else in the app when a specific piece of data changes, and only when it changes, regardless of whether one or many related components are on-screen at the time. So refreshes aren't based on which DOM component happens to be on screen and whether its key matches some state, and consequently, you don't have to hunt for every component that might need that state. Encapsulating states in component-level architecture is stupid if you're dealing with apps that have hundreds of components and need to abstract model changes to any or all of them. Looking at React code and trying to figure out how to turn off specific listeners, or only target certain elements in sub-components when big models update seems like a recipe for hell.
And I also don't get why something that came out of Facebook has gained such popularity. Have you looked at Facebook's website since 2011? Is that a framework you would use to build an app?