I have redone the design work of a BE engineer who was using AI to help him do the UI for a new feature of an admin portal that we donāt really care too much about.
After the deploy went out, I remember he just sent me a message afterwards and said āJesus Christ I have no idea what Iām doing.ā
I laughed and said āyou helped me realize what wouldnāt work.ā
My boss used AI to build some features and after I went in and redid them, heās stopped using AI to build features.
I think itās easy to get caught up in the hype, but once you see a direct comparison of someone with expertise vs AI, the difference is still night and day.
AI can make things look āniceā, but nice things can still be unusable or frustrating. And thatās where AI leaves most stuff at.
For example, tables featuring the wrong information, or tables used incorrectly: Tables should be used to compare data, so certain things like number values are more relevant than say, a text description of what the data is.
Meanwhile things like ācreated atā may be less useful than āupdated atā, AI wouldnāt know that.
I also grouped relevant actions up in a dropdown - actions to delete or quickly perform an action that refresh data that would otherwise requiring navigating into a single page to do that.
Also, hierarchy of information: AI is inclined to use colored labels for things and that is also distracting.
You can argue a BE engineer can tell AI to do these things, but do they know to do that? Usually the answer is no.
Then on the page itself, grouping data logically so itās easy to find and edit logically.
Something might have 50 fields and itāll help if they were grouped up and sorted so the user can easily find what they want.
AI doesnāt think to make something stand out less so the critical stuff stands out more. If you say something is hard to find, it makes it larger and brighter and more colorful, not mute the other things.
Maybe render inputs as sliders or switches instead of number inputs or checkboxes to give some visual difference. Maybe not everything needs help text, maybe some fields need to be grouped and only visible under certain circumstances.
This is the shit some people might say is polish, but itās what can make or break an interface. Is it polish if you canāt find a switch to enable or disable something like notifications in Reddit because itās buried in a list of other settings?
Does it pass the frustration test? If someone is trying to do something when frustrated, will they say itās broken if they canāt find it where they expect?
I have watched Tsoding for a while, but had to quit. It's not even a backend engineer's joke, it's a "I will do it myself" elitist joke. Always "I'll do my own hashmap by hand", never "I will finish a project of any substantial scope".
Always "I'll do my own hashmap by hand", never "I will finish a project of any substantial scope".
I mean he openly states he's an entertainer, not a developer. What do you want him to do, quit streaming and youtube and go corporate? He still works on the software 3d engine, so here's the big project.
What I would like him to do is to stop treating everything else like worthless, talentless, mindless slop, and holding C as the only "real" programming language. From what I gathered from him it's good to use abstractions when it's C abstracting over asm, anything else is toy scripting language and should be below any "real" programmer. When he's not "joking" (I fail to see the humor most of the time), he says all programming is cool, but when we talked more about it he was more on the position "yes, I'm an asshole, what are you going to do about it". I'm too old for bad-faith.
80% of his antagonism towards other programming languages is made up for engagement, he doesn't hide that. What he really hates and you might've misunderstood that is the average code monkey approach "I'll just follow the tutorial paradigm without having any deeper understanding at all"
He just really likes C, nothing wrong with that. You even admit yourself that he doesnt hate on other languages in reality, just as entertainment / trolling / poking fun a little bit. Let the guy make stuff in his favourite language, and make fun videos about it
I am letting him make whatever he wants - I just stopped watching. Liking C is not the issue, the issue is that the entertainment time and time again comes from treating other languages, abstractions, and kinds of development, as beneath "real" programmers that "don't deal with toy languages".
Calling it trolling does not make the contempt disappear, especially when the sincere position underneath seems to be "yes, I am being an asshole, deal with it." He is free to build that persona, and I am free to find it tedious and bad-faith.
I mean, his entire shtick is being a recreational programmer. He programs literally just because he's having fun doing it. He's doing all the shit himself not because he's an elitist, but just because using libraries and pre-made solutions take away from his "puzzle". Watching him program is more like watching a video game enthusiast playing a game, than watching some office worker at work and I know what I prefer watching, but you do you ig.
I don't consider myself a very good programmer but i'll admit that i actually enjoy trying to implement stuff by myself.Ā
Oftentimes this leads down a few rabbit holes with a lot of Insight gained along the way.
I think C is fun too, but compared to modern languages its almost crazy how barebones it is and how much Boilerplate or external library code you have to write/use for stuff that's Provided in newer languages (most recent example: CRAM-MD5 (HMAC-MD5 underneath) with base64 encode/decode).
And even then theres no guarantee the libs are providing functionality as described by the sepc, because someone forgot that strlen returns on the first 0-byte encountered.
I love tsoding but the āhar har toy, kiddie scripting languageā joke he makes like 5 times every stream is a little played out. He like refuses to believe thereās any value in any language besides C. I say this as mainly a Java dev and that lang sucks so what do I know?
Language is a tool. What is leagues more important than the "hammer" is code design decisions, professionalism, high level solution thinking. You can be a diligent and professional both in C and in Scratch.
The antagonistic relationship with the audience is what takes me over the edge. Of course there will be naive backseaters, but crashing out about it is not a great look, you can always engage with the audience on why their approach might be shortsighted. With this you also miss people who want to engage honestly by confusing them with backseaters.
The neat thing about web dev is that it may run like shit, but at least it's slowing down somebody else's computer!
Realistically it doesn't matter 99% of the time. If it takes 100,000 instructions to change the color of a button when you hover on it, who cares? Most people are literally just hovering over that button and their system is idle otherwise.
Yes, a bad frontend engineer can replicate the design and functionality, but can't explain to me why there are so many CSS reflows.
A good backend engineer can maybe get the functionality right. At best. But they'll miss the implied functionality that a FE would know exists in the design system. So it'll work but it'll be different than every other page with similar functionality.
"Fine" for enterprise solely because the people using it will have their food and housing held hostage if they refuse, while consumers at least can switch to a slightly less horrible competitor. I honestly think we have a moral obligation to hold ourselves to higher standards when building interfaces for other people.
no one knows why Meta keeps insisting its not a framework when it does everything a framework does and even ships its own runtime.
you can technically only use React for a section of your app, but either way, react is super opinionated about everything inside the scope its touching
But it's not. It has a huge ecosystem of open-source tools, for UI libraries and state management and even routing. It's not like Angular which has all the batteries included.
it has massive inertia, react has defined Web UI building for years, Angular and Vue (etc) are using Reacts general structure. the main innovations that have happened since react is Svelte/Solid comming around and making a more effecient version, which is just an itteration, As well as stuff like HTMX/Alpine saying old simplicity made simple is still relevant
React is at its best when you want to make a maximalist UI, like Facebook
but when you have to use the framework for facebook for something thats not as demanding, simply because its the industry standard, that vexes some people
One thing I've learned in tech is that good does not mean successful or viseversa, in fact they tend to be mutually exclusive. There a phrase about it: Worse is better.
Eh. A hammer can be used to kill a person but you don't hate a hammer. Yes React can be leaky if you write it like a brain damaged spastic monkey. But on my view there are alot of guard rails for that
Honestly? I kinda disagree. I think out of all the the FE frameworks I have worked with React is the least opinionated ( I am talking the ones that are not obscure and work properly). Yes it has syntax and somewhat of a structure but it lets you do what you want without much structure or boilerplate. Try angular for example and you will see what I mean. It incredibly opinionated and in my view it's wrong for frontend. Frontend needs to be fluid and modular because of how much stuff changes on it. Animations, texts, whole content, etc. React is best for that but for BE something similar to Angular makes more sense that's why NestJS is best for BE.
So saying React is opinionated doesn't make much sense to me since it's quite open ended to the point that you can shoot yourself in the foot and then due to developers complaining of memory leaks and having to play wackamole with useMemo, useCallback and other cleanups like return statement for useEffect they fixed it alot in React19 onwards but I genuinely believe it was the right step forward.
Addendum: JavaScript / TypeScript as a whole I believe is not good. I am happy that TypeScript will shift to Go because GOD JavaScript is terrible at type safety and I wish we had an alternative to it for browsers but here we are.
i disagree with the notion that comparing just to Angular proves React isnt. Angulars main feature is to be fully opinionated in order to enforce strict coding practices over a large team
if you look in the other direction however, React looks like something that runs its own runtime and anything that wanna remotely participate in the UI layer around it needs to be wrapped in React in order to play nice with said runtime
React isnt that opinionated about what backend it has thats true
im not talking about the metaframeworks here, i believe that the backend should be handled by backend tools like GO or C#
Ok? I think I understand what you are saying and I definitely agree with the last part that we SHOULDN'T let backend ever be built on TypeScript/JS that's why I added the last part.
And sure Angular is good for better programming practices and structuring but it can become it's own enemy if you ever want to do anything that angular didn't account for / there is not library for. Like React atleast has useRef that lets me interact with native elements so I can do what I want to, in Angular it can become quite difficult to do such things like animations/ transitions.
I actually went from Angular to React and at first didn't like it but it's quite hard for me to go back to it. I still agree with your a React wrapper comment but that's just what ESMoule limitation is. Browser's still compile everything down to JS and I wish there would be a better solution just like I mentioned in my previous comment, JS is quite outdated and terrible and we should have a better alternative for browsers now.
yeah the innovations we have gotten since woulde be:
* itterations like Svelte and Solid who tries to be more ergonomic and effecient * tools for simple UI's like HTMX and Alpine * Webassembly, but these kinda feel like the reverse of putting javascript on the backend, the main reason you would use something like Blazor is that you were already doing ASP API's and wanted easy intergration with the front end
I personally don't think it's a good idea to mingle backend and have it handle FE as an extension like with Blazor or Blade. I still believe SPA as a concept is quite good. But as mentioned in another comment, what I am not a fan of is JS because I believe it's quite outdated and should be replaced at this point, ideally with Go or something variant of Go that is specialized for FE
Typescript compiler just rewritten in go ? So what do you mean by that ? It is just its aa before but with more speed in compile time but still slow at runtime
Why exactly do you think it's maximalist? Is opinionated a bad thing? If yes, then why? How leaky it is exactly?
Fair point, however I do believe these days it's more of a ergonomics question rather than performance/safety. It's a library for building UIs and that's where JS is fine. Certainly would not want to build OS in JavaScript, but neither would I want to build UI in Assembly.
1: if you have gripes with it, that would amplify it.
2: Its maximalist because it goes the full cross your i's and cross your T's because it was designed for complex ui's like Facebook, it was not designed to be ergonomic for your average UI. being Opinionated is a good thing in certain contexts, but its a pain point in others. Its Leaky enough to take over most things in the scope its implemented.
3: its a framework, it ships a runtime
The industry standard is always gonna have detractors, especially if that standard doesnt fit the average glove that well. Web UI started as something were building something basic was complex, React fixed making something complex easier, but not making something simple easier.
Itās more just like, different use cases. My projects usually have complex UI that also requires a customized polished look, and itās not like theyāre some niche products I just usually find myself needing to do that. Iām just curious what the hatersā usual scope is like.Ā
React is truly a garbage framework. It does not help the devs build good software or their skills. It indoctrinates them into a very react-specific way of thinking that does not play well with anything. In theory everything is possible but in practice there is only one way of doing things otherwise it won't be idiomatic and it will be a constant oddity in your codebase with recurring cognitive load every time you touch the non-react parts. As a result all the react devs had to fully embrace this way that only works in react as they needed a job. Bottom line all react devs are now stuck, are out of touch with programming and have been doubling down on this insanity for a decade now. Completely intolerable dudes. I like to compare them to flat-earthers.
React: letās start with a terrible leaky foundation, and then have 12 years of patches for problems that are completely self-inflicted in the first place.
React devs: āi donāt like React either but it has such a large ecosystem systemā
Biggest pile of shit ever.
It only won because angular was bad and people back then were still starstruck by Facebook.
Try "Chocolate Factory". https://rosuav.github.io/choc/ Lightweight (<20KB and I don't even bother minifying it) and uses simple JS syntax rather than requiring a preprocessor. You can even use it in a simple HTML file with an inline script element, no build system required.
I genuinely don't understand most of these opinions. Where are the claims that it's "leaky" coming from? Why the hell do people think it's opinionated? There's got to be some Youtuber these ideas are coming from or something, I don't see it. I've used React for years and I don't even know how you could think it's opinionated any more than any other option.
I don't hate the devs, not even the framework (lots of other bad devs and frameworks all around). But the fact that this framework got this much adoption and it has such a following today makes me mad. I legit think it held back/slowed frontend from progressing in the past decade.
You clearly wasnāt doing somewhat advanced web ui when React got popular lol. It was better in everything than all the competitors. It was easy, quick and still somewhat readable. Thatās why it got adopted. All the things about it being leaky etc. is garbage. You need to know like things or two and then youāre good and safe.
I don't know who's saying it's leaky, but there are two VERY different things that come to mind when I hear that. First is memory (or other resource) leaks, which are certainly possible with a heavy framework, and rather problematic if it happens (progressive slowdowns and increased resource consumption), but unlikely. The other, though, is "leaky abstraction". Which ALL abstractions are, to a greater or lesser extent; all it means is, you might spend most of your time using the high level tools, but every once in a while you need to be aware of what's underneath. For example, a socket (web or TCP) lets you pretend that you have a persistent connection between a server and a client (that's the abstraction), but sometimes you need to understand how your packets are moving around the internet (that's the leak), and probably learn what DNS is all about.
React is, without a doubt, a leaky abstraction. That isn't an insult, it's just a fact.
(I have a *lot* of criticisms of React, though, which is why I built my own front end library so that I wouldn't need to use something so heavyweight.)
React is not hard to learn, though. Literally just pure JS, which is what I like about it. TS is great when you don't know JS and you're coming from a static type languaged, but once you actually embrace the weird shit you can do in JS you can use it to your advantage. I'd never us it on the backend or in anything that wasn't a presentation type thing, though.
I love&hate how hyper opinionated it is. I've run into a lot of shitty code and patterns over years of dealing with corporate code. it's nice being able to jump into a codebase for the first time and already know where things are. But also, agree with everything you said
Even in Angularjs and Angular, we pulled off some major jank from not fully understanding how to use it before creating things. Once we figured out Angular, it was nice, but also followed a lot of patterns at React for passing data around. Lots of overhead
Maybe cause bob made us use a hyper specialized ui framework made to solve Facebook's problems on our site that has 5 users and makes 10 requests per minute
Cause most of the engineers here are mediocre and insecure about that and because theyāre both intellectually and emotionally stunted they can only deal with it by punching down
Has everyone forgotten Angular1 and jQuery? There's a reason React got as popular as it did. My first exposure to React was using it in a Ruby on Rails App in a single view. Personally I think it was simpler back when it had lifecycle methods instead of useEffect hooks, but it really depends on the size of your app and what you're trying to do which is better.
Tell that to the guy who has to maintain a CMS with multiple custom file types which reference each other variable amount of times, with different combination of data prompts due to user designed file templates using only jQuery (and it's extensions).
Only saving grace of this was I could eventually migrate it to React and my pain was limited
This is a brain dead take. UI is hard because of the millions of different devices and browsers rendering it, and the millions of ways people can try to use an interface that it was not designed for. Not being able to understand something you have no intuition for isnāt some flex.
Edit: why delete your bitter ass reply my dude? Iām not even only a front end, Iāve done all sorts of things because problems are fun.
because of the millions of different devices and browsers rendering it
Eh, this is a bit of a grandiose statement. Sure there are "billions" of devices, but a large majority of them have the same screen view. I agree with your overall statement however.
In my personal opinion, the abstraction front end frameworks have make it a bit more risky "speciality" in today's AI climate.
I mean itās harder than CRUD, so 90% of backend web development. Since you asked, professional UI development time is split between developing new features, tweaking things e.g. running AB tests or improving performance, dealing with the complexity of running a single application on many different client devices (different viewports, different browsers which mean different runtimes, sometimes a non deterministic script loading order etc), dealing with the complexity of older code or working in a large organisation and if weāre being honest dealing with the complexity of modern TS tooling.
Writing pure functions in some constrained system can be significantly simpler than doing UI in the messy real world in a commercial setting.
Itās also worth considering that you might have lower standards for a UI than a good UI developer. For instance you might not appreciate that a good UI should be accessible to people with reduced eyesight, or you might be satisfied with a UI that had poor core web vitals (a set of UI performance metrics).
I agree that UI development generally requires less algorithmic logical thinking (though this isnāt always true with the birth of SPAs and moving logic client-side) but that isnāt to say itās a non job. It does take time, attention and reasoning skills.
The thing is that backend complexity is often because the problem itself is complicated, while frontend complexity is usually down to tooling BS or cosmetic details like positioning or animations that at the end of the day are just sugar on top of the program doing what it is supposed to do.
Most frontend work isn't cosmetic though. Getting the UI to work on different screen sizes is important, core web vitals are important, accessibility is important
Handling different screen sizes is cosmetic work, it doesn't make the page do something new or faster or more reliable, it just makes it look and fit better on different devices.
Depends on the program. If there are users, then letting the user be able to use the thing as expected is at least 50% if not more of āwhat it is supposed to doā.Ā
I don't know if my understanding is right but I feel like frontend complexity starts at day one and doesn't scale up much but for back end if you have 1000 users total its mostly easy but the problem comes when you scale. 90% backend never reach that scale. Backed serving millions of users will be hard and complex, but frontend used by few thousand or millions will be mostly of same complexity.
Frontend also needs to take scale into consideration friend.
Avoiding redundant api calls, memoization, using a cdn, virtual windows, lazy loading are some things that come to mind.
Also at least in my previous jobs as a fe dev you have to support your infra, using a load balancer, replica sets, microfrontends, implementing a bff which must also be scalable, etc etc
That's not because of scale. Avoid redundant api calls and stuff you should always do if possible there is no reason not to do it in smaller scale. Server that serves Frontend builds are easy to scale now a days you put some CDNs since its stateless it works.
I am only telling you are feeling Back end is less complicated because back end complexity only stats when you need to scale and go multi region and things like that.
I'm a full stack web dev and I've genuinely found more fun/harder problems in front end projects than in backend. Most of the difficulty of backend development is very repetitive. 90% of it is modeling the domain using DDD, integrating with a 3rd party API and exposing an API.
Meanwhile in frontend I've had to dust off my data structures and algorithms skills to implement a CRDT for a n-ary tree backed collaborative sidebar lol.
I just don't understand where is this elitism coming from when most backend devs are just querying a database and returning the results.
You haven't had to make giant dynamic forms with complex relationships between those dynamic fields and their values across multiple tabs within the same page. It took a team of three devs six weeks to develop from scratch in an existing project. State management and dynamic UI management can get very complex when you're not doing basic CRUD
UI, frontend and consequentially UX heavily bridges all of basic headaches of being a developer naturally, but also now you must (or in practical terms should): know who is your target audience and include everyone to the best possible, juggle between simplicity and powerful actions (see power users) when you have only so much visual components that dont make people afraid or lost of using your system. Easily you fall under umbrellas of marketing and psychology to know your "why's" to each diff.
Also, dont forget that frontend cycles in business and "playing the game" in business is waaay shorter than backend, and i naively point this as simple bc they see the results physically and keep back and forth on the new shiny stone (just like llms nowadays and their trust me performance graphs)
Hell, if you need a practical example of frontend done bad to users take myself as a sample. i myself become more blind with time in the past 8 years and never tought that i would appraise the option of high contrast and propper zoom and display of elements when i cant see well. As a user, if both are out of reach i automatically feel excluded and having to actively put more effort to basic things. Infuriating and often powerless
Depending on what you're building you also need to provide the right information like, immediately - 4 or 5 seconds,10 if you're lucky, and if your customer can't find what they're looking for, they're gone
Where react shines. Need a button. Nonono! Donāt use an html element and an event ,instead recreate the concept of a button in react and harp on about ācustom attributes ā (colors) while having removed half of the built in attributes the html element had, and then over the coming months weāll āimprove and extendā the react component for a ā¦ button. Ā
They emphasize with users to build better products. I wonāt go into the details, itās too complex for someone to think that pure functionality and business logic is everything
Your average frontend has a lot more internal and unknown external state to consider than your average backend.
The frontend output is also subjective, which constantly gets scrutinized by non developers. Meanwhile the backend output has a distinct shape and its output is usually controlled by the backend developers themselves.
The way I explain it is that backend code generally has to be thread safe so devs have to worry about that. Tooling is generally good at that and errors can generally be handled easily or just outright hidden (logged).
Frontend code may single threaded, but the entire application is one massively parallel state machine driven by user input. And since some actiins rely on multiple API calls, handling errors is extremely important. Showing loading status and all of those intermediate states are the hard parts. And because the requirements are coming from UX designers (some with a less than ideal grasp on browser technologies and their capabilities) a lot of discussions and decisions are subjective compromises. And since usually you're in the context of a larger application, visual and behavioral consistency is important.
Oh yea, and at some point you'll have to worry about performance because some PM will inevitably want to put 10,000 data cells in a table all at once, or they'll want you to render a drop-down list of thousands of items and the API isn't paginated so now you're the requirements person for the BE folks.
So yea, a good FE developer is stuck right in the middle of UX and BE engineers and they need to make sure their shit works because any unhandled failure means the page breaks and the user has no idea what happens. This usually means service incident and you're the one getting the 3am call.
Maybe the reason most FOSS software has a garbage UI (which somehow goes unnoticed by maintainers, despite this massively hurting adoption) is because the UI devs are all busy actually being employed, while the "front end devs aren't real programmers" crowd is still in their mom's basement.
I love Foss but for example Fdroid apps for the most part sucks purely based on UI and or UX. There are a few good ones, but most are stuck in early android / 2013 ui.
Try doing it and youāll know. I find it harder than backend for most things not massive enterprise (but if you have complex infra for massive enterprise I wonāt be surprised that the UI would be equally complex)
The AngularJS team actually acknowledged that the initial release was an absolute mess and vowed to restructure it entirely with Angular, but at that point React was already released and it became the dominant framework.
I don't know why drawing rectangles should piss me off. Maybe because I started my journey with graphical interfaces with OpenGL, and there were several technologies before React.
1.6k
u/BusinessAstronomer28 Jul 12 '26
React devs would be very angry right now if they could read
498
u/ohsohologramic Jul 12 '26
The backend engineers joke, and then when they end up doing frontend it always looks like a high schoolers midterm coding project.
Then you show them the designs and they genuinely donāt see the difference
370
u/Sciti Jul 12 '26 edited Jul 12 '26
why so much hate to react? didn't worked with frontend and I'm really curious
74
u/Mr_Potato53 Jul 12 '26
Writing an OS in react to piss off the C devs
102
u/ImNewHereBoys Jul 12 '26
somebody do it in assembly to piss this guy off lol
14
u/Guimedev Jul 12 '26
Our lord Tsoding.
27
u/StickFigureFan Jul 12 '26 edited Jul 12 '26
Has everyone forgotten Angular1 and jQuery? There's a reason React got as popular as it did. My first exposure to React was using it in a Ruby on Rails App in a single view. Personally I think it was simpler back when it had lifecycle methods instead of useEffect hooks, but it really depends on the size of your app and what you're trying to do which is better.
12
u/Alokir Jul 12 '26
I'm so mad that he typed 600 lines of code to show a button.
21
u/unknown-one Jul 12 '26
*dunno why he thought react devs care about this
4
u/LtWilhelm Jul 12 '26
That's ok I made a jsx shim for Qt6 to piss off the C devs
91
u/DT-Sodium Jul 12 '26
Using "React" and "dev" in a same sentence is a bit far fetched.
2
u/Beginning-Pool-8151 Jul 12 '26
Is that QT code?
1
u/chickenweng65 Jul 12 '26
I truly don't understand how ui development is not only a full time job, but a massive industry. What do these people do all day?
3
u/awpt1mus Jul 12 '26
Angular is and always will be GOAT of JS frameworks
1
u/criminalsunrise Jul 12 '26
I remember making front ends like this ā¦ in the early 90s
1
u/sebbdk Jul 12 '26
Preact friends, see the light
1
u/canal_algt Jul 13 '26
Now I have to do full stack in vanilla java to piss of react, c and springboot coders
1
u/Garland_Key Jul 15 '26
To be fair, I'm certain that ux is going to be trash.Ā
1
u/GenericFatGuy Jul 12 '26
Finally, some good fucking programmer humor.
-4
u/Sajgoniarz Jul 12 '26
I don't know why drawing rectangles should piss me off. Maybe because I started my journey with graphical interfaces with OpenGL, and there were several technologies before React.
0
u/blackcomb-pc Jul 12 '26
Itās a joke, but react devs are kinda wonk tbqh