The author is frustrated with modern frontend development, saying it has become too complicated with tools like React, Tailwind, and JavaScript-heavy setups. They believe simpler methods, like old-school jQuery or basic server-side rendering, are often better and easier to manage. They think developers focus too much on trendy tools instead of keeping things simple and practical. The author wants people to prioritize straightforward solutions and only use modern frameworks when truly necessary.
@mortenhauan Is it really that complex? Choosing react for everything isn't a js issue it's a team leadership issue. Don't blame react for poor leadership decisions.
@@mortenhauan As the author of the article, that's it in a nutshell with a minor correction: It's not that I think jQuery or "traditional" SSR is better. It's that they are less-complex solutions, and I think we need to prioritize the least-complex solution for the problem. Theo completely doesn't grok the point I made about jQuery at all because he was too triggered by the mention of it.
This guys blog post is completely incomprehensible to Devs who have had the luxury of never being forced to wade into the truly horrific and utterly sadistic enterprise and/or outsourced codebases that are literally decades old. I understand every word of what that guy was saying even if I knew he was off-base in a lot of it because that dude has simply never seen a codebase written in javascript that wasn't a complete and utter disaster zone the likes of which I guarantee you 80%+ of the people reading this can't even comprehend. It's literally soul-sucking, I've been forced to work with code that gave people clinical depression, and unnecessary Javascript & build tools multiplied an already miserable experience by maybe 3 to 4 times what it was. The only proper response to that guy's post is pity and the kind of support you'd offer to someone who's standing on the edge of a cliff. Who cares about their bad takes on jQuery bro this is literally a cry for help.
Same with php and js... Working in a custom CMS, a small company, no types no docs pure suffering and pain... NOT EVEN GIT... LIKE WE ARE FORCED TO WORK WITH FTP AHHHHHHH
@jabbruh I've been encouraged to work with FTP exactly once, in college, and I never touched FTP more than a handful of times. That was almost exactly the same time I started watching Prime, and decided (for no particular reason) to learn vim and HTMX. Simply SSHing into the server and learning to use vim while simultaneously learning webdev and modifying the assignments to work with HTMX was _much_ easier than the headache I just _knew_ trying to fiddle with semantic versioning and FTP would be. And that was all solo project stuff, I can't even _begin_ to imagine how bad working on a _team_ and fiddling with that stuff would be!
Coding with AI editors will only amplify this issue. AI loves to generate hundreds of unnecessary lines of code, and the new no-code natural language movement will lead to an unimaginable quantity of software bloat. But what do I know anyway, I am just a react dev who uses Cursor too.
uh, it has improved quite a lot. I haven't used copilot for a few months and this week I fixed so many bugs in 1-take. It's also updated and pretty much connected to internet so i'm not sure the argument of "ai spitting out unnecessary lines" holds up. Let's be honest. AI will do it all, you won't need to write code. 🤣
1:14:58 No, you don't need to make 3 copies of the same method. You can just put a data-attribute on the HTML button element and then read that in the method. It's a class selector, and not an ID selector for a reason. You may dislike that, but it's in fact very similar to putting props on a React component.
Where does the data-attribute come from? How do you make sure it's globally unique (answer: you can't). This might not be an issue in small code bases, it all depends on what you're working on.
Most likely you would just put the data attribute onto the button element when rendering HTML on the server. In this example you would just do something like: const id = $(this).data('id'); inside the class selector. In this particular use case the data-attribute doesn’t need to be globally unique, but admittedly the class does. Yeah, it’s definitely something that becomes an issue on large codebases with many devs. I like React and similar frameworks for larger projects with a lot of interactivity.
The author clearly stuck in a phase of "what I used to do is simple. What come after that is adding complexity". I lost it when author show JQuery syntax with a lot of $ sign and weird JSON and say "see how simple it is?". I can read that very easy today. But I still remember the first day I learn about JQuery with similar example and I was like what the hell is this dollar shit. What the hell is Ajax? What the hell is a soccer club in Netherland have anything to do with web development. And what the hell is () => { }. And why does this thing does not execute in order? etc etc. This is not simple, readable and intuitive at all. That JQuery code is simple to the author just because he has been in the space way too deep. It is not inherently simple. There is an inherent complexity that come from badly design technology. But author seems to not able to differentiate that from simply something he does not know. Like, LISP and Haskell is simple once you understand it but takes time to learn. On the other hand BASIC programming language back in the day with GOTO is really easy to learn and grab at first glance but get complex real quick. Author seems to think like "everything I know is simple. Everything I don't know (or know but don’t use as much) is unnecessary complexity".
I agree so hard. I've worked with vanilla JS for 90% of my career. I am a freelancer who specializes in pagespeed opitmization, so using Jquery is completley unjustifiable to me. You don't need any of the abstractions Jquery offers, just like you don't need abstractions that React offers, but I think the author is more comfortable with Jquery than React, so he sees Jquery through rose colored lesnses.
I am very surprised that Theo never said the word "declarative" at that point in the video. I have worked in crazy complex imperative jQuery code. The best part of React (over jquery) is components having a declarative pattern.
Complexity comes from having lots of uncontained state on the front end. MPAs are extremely simple because the DB owns the state. Now, MPAs are not ideal for everything, like when you have truly heavy state on the front end. But many times developers think they have a lot of state but don't realize starting with the SPA mindset causes there to be way more state then should have been there to begin with.
Yes! I am a 2023 graduate who wrote their first line of code in 2018. Back then we had a web development course with Laravel and PHP. Seeing the syntax and ecosystem was very difficult to grasp and I barely understood anything. So much so that for the next 2-years I swore I'd never be a web developer. Life has a certain humorous irony as since then I've become fullstack RestAPI web developer with all kinds of tech stacks. Comparing my code and diary notes then to now is entertaining in how much has changed in such a short span of time and how far I've gotten from those early days. Now reading PHP is like reading a native language and everything is just so logical, clear and obvious. But that's exactly why professionally exposure and experience is so important so that you learn.
You forgot iOS and iPadOS... But there are two solutions. You can either use the hover media query to use hover only on devices that support it and use JS for other devices. Or you can add the onclick attribute without value to the body element. Then also iOS and iPadOS support :hover. This sounds like a joke, but it's not. Sometimes Safari is the new Internet Explorer. You can also use :active if you add the tabIndex attribute to the wrapper element.
In my experience a lot of frontend developers do not know CSS, they know how to style a specific item, but not a whole page. dealing with !importants sucks for sure, it is why i do recommend tailwind, since it is scoped just to itself overall, it makes things much easier overall, and being able to extend it for your style is awesome. I know ive seen pages with multiples of the same class doing ther same thing, and the same class doing different things, both sucks. CSS is definitely not as simple as people think, but it is also quite amazing what it can do with such simplistic rules
I tried hard to find 'Being "Early" Is Hurting Your Career' the screen shot says 1 day ago. I fiund it 5 month ago with different title an other imager. Currently ist called: 'Stop Using new tech (seriously)'
8:31 Ugh, this is why I have to leave the tech world (or start my own company). Leaders believing that it REALLY matters that an engineer cares about their product. 1. Products generally aren't difficult to understand. 2. Humans have most things figured out already and most humans wouldn't need to work. 95% of software engineering (and even more managing those products) is busy work. Believing that people have to deeply care about a product to not only understand it but also deliver great results is insane. Born out of some weird management cult mentality that took hold of the tech world what seems to me a few years ago. At least around 10 years ago, it was largely still OK to just want to earn an income and enjoy creating things by writing code. What you do have to do is care a little. (And take pride in your work. Which, admittedly, few seem to do these days.) You can still think that the product is a steaming pile of garbage but try to make the best out of it for the sake of the users. And because you're getting paid for it!
I admit, I was kind of like that back when I was a backend developer (mostly Java). I didn't think frontend developers were "real developers" and I wasn't alone in that kind of thinking. Every backend developer I worked with had an ego problem. Now, I cringe when thinking about some of the conversations I had with team members.
my advice is: choose 1 framework and stick with it. It is no different than the others and you save a lot of time. I started with react in a bootcamp, learned nextjs after and thats it. Maybe theres a new framework that is 10% better and blablabla I dont care, I just use what I know and works
@@IvanRandomDude Indeed. The minority are the loud people who have the fear of missing out. The "front-end problems" are not unique to front-end. It just happens that more people are doing front-end, and naturally you will have more voicing opinions about it while others do actual work.
@@dealloc i mean everybody knows that early adoption is a bitch, it's all fine and dandy until you start to notice the limitations of the new framework and 0 docs or help online because you just jumped at it. Best way to really know if new frameworks are actually better for you is doing some side project
The stress i get from this image is crazy 💀 Most of the time right before i give up on a solution i worked for hours, it is most of the time resolved by a work that should have taken only 2 minutes 52:30
I principle in naming CSS class name simple, just use random characters or with short characters (3 to 8 characters) this way it will not added to the output side of the page and css file. literally front-end devs can just inspect/search that class name and they will just understand.
As the author of the article, I definitely appreciate the promotion. But a few things that should be mentioned: 1. My experience is almost exclusively in content management. Theo's experience isn't. We've had different careers and that explains much of our differences in perspectives. 2. Theo calling an accessibility bug on my site a "CSS skill issue" demonstrates his immaturity as a developer: he'd rather choose an ad hominem argument (attacking my character / person) than simply labeling the issue as a mistake. Which it was. Bugs are bugs; there's no need to insult people for them. 3. Theo only knows what he read in that article. He didn't read the other articles where I: Provide naming conventions for front-end code Describe in detail the problems with nesting, both in and out of Sass Go over different problems front-end developers experience in content management scenarios Explain how to debug CSS Explain how CSS Specificity works Explain how the CSSOM works Explain how to read a CSS Selector Explain how an em is computed Explain CSS 4 fonts Explain how to write CSS for a CMS He only had an hour and a half, so I don't fault a guy for doing the best he can with the resources he had. Thanks, Theo, for the promotion. Feel free to reach out to me if you want to continue the discussion.
On 2: The CSS skill issue point is an illustration of why you can't just ask people to _for god's sake use the platform_. Mistakes happen; and there are ways to eliminate whole classes of mistakes which you are dismissing without enough justification (Tailwind is just a good set of utility CSS classes and build-time / IDE-stage tools to automate that). On that note, "immaturity" is a far worse personal insult than "skill issue" / "'clearly doesn't know CSS' ... so I guess writing your own CSS doesn't make everything better". As a reader / audience member (edit: and someone with far less frontend experience) I do look forward to more discussion though, if that could happen.
More on the skill issue point: 40:34 Explaining tech to non-tech people is a situation where there are two approaches to make it easier: change the stack to make it easier to explain, or get better at explaining it. Doing styling correctly is the same: use whatever tools one knows of, or just get better at CSS. Both options for both situations are sometimes valid. But the article is discrediting valid tools because people should just learn to do it right while still showcasing there are limits to skills. This is, I think, why he said "if the author's going to skill issue me I'm going to skill issue back".
To be honest, Theo has always been like in point #2, lots of ad hominems and other sorts of churlish insults in many of the other videos he makes. It's just the sort of content I'd expect from him these days as he seems incapable of critiquing something fairly if he doesn't have first hand experience with it.
How the hell did you list a bunch of blogs about how to deal with the insanity of CSS and then say with a straight face "Quit acting like CSS is some giant-ass mistake that needs fixing... They didn’t make mistakes". You realize the W3C CSS Working Group literally has an article called "Incomplete List of Mistakes in the Design of CSS" with FOURTY EIGHT bullet points? Even the official working group doesn't sniff their own farts, but don't let that stop you. "Just… grow up and think."
For me CSS is not hard at all, just write the name of the component in the class and you are good, much harder to deal with tailwind edge cases. And don't forget we have css layers now
React content is bottom of the barrel content. Easy to put out since you don't really have to do anything creative yourself, just give a few quips and opinions on other peoples stuff. The thing is: people gobble this shit up and watch it, so thats why its popular. If it didn't get views and thus money creators wouldn't do it. So in reality its not really creators faults, its what viewers ask for. Go into any youtube comment section or twitch chat and you'll see people begging them to react to something.
"I'm still relatively new to Frontend, I started in 2018." 2018, 2019, 2020, 2021, 2022, 2023, 2024. Bluds been doing frontend longer than I have been doing applications, graphics, and games programming. (3 years.)
New dev here, what is Theo talking about here 53:31 with pre-commit hooks and ides? is he talking about an extension to run the pre-commit hooks or something else?
Dont understand when people say things have gotten sooo complex. Im using react, tailwind, tanstack router and tanstack query for a legal case management system im building. Bruh just make an api call wrap it in useQuery render the data. Add bg-blue-600 to the button move on lol
1:03:54 holy shit fuck everything about that statement. jQuery is such a pain in the ass I still prefer using 10 lines of native JS to writing out a single line containing jQuery. I disagreed a ton before now, but this was my breaking point.
I agree with a lot of what he wrote in the article and kudos to him! Finally people are beginning to say it lol! 😂 As soon as we got front-end "react Andies" js is used everywhere now even in many places where it shouldn't. Also, I do agree with the point that it's nice when the same language is used for a full stack but I chose something other than JS... Soon people wouldn't need js for the client side work is already on its way in that segment...
25:00 I mean maybe specific *termization* with the abbreviation, Server-Side Rendering (SSR), didn't exist but we've definitely been saying it was "rendered on the server" for a long time. I'm glad the recent 'industry term' is intuitive where people can be anachronistic with it, and I don't think conflating the term with the reality is that big a hit to their arguments...
48:00 - "I never liked the idea of generating classes based on a set of values" Theo, you've *just* been praising Tailwind, what on Pluto are you talking about?
33:00 Astro is not jsx, they have their own compiler. I tried using Astro but immediately hit compiler bugs 30 minutes in, tooling around real jsx is flawless.
28:20 - I'm sorry but I kinda chuckled over the whole "group" thing in Tailwind. That moment when Tailwind realizes you need cascade, so it has to emulate it. 😂
29:00 - but the apperance and disappearance of the buttons is not part of the markup content, it is just a concern of presentation. The fact that the buttons are hidden and are only appearing when their parent is hovered should not even be part of the markup at all. Even from an accessibility standpoint this is plain wrong. The buttons are and should de-facto be always there, execept if you want to make even the keyboard navigation to these buttons modal. The fact they are invisible and reappear are part of the presentation, not of the content and it should not even concern you when writing the markup.
45:50 "I've never seen this behavior actually being written before" I've actually written that behavior before. Usually only in the context of 'this component behaves differently if its a child of this other component' or 'this has a different feature-attribute-flag on the parent'. Every case is to keep the styles altering the component in the Scss/Less file for that component and 90% of the time the nesting stops at that level.
Just to nit on details: Astro is not JSX (but Qwik and Solid are for example). Astro is JSX-like, but has more html-frendly exceptions, like you can't use jsx templating inside scripts or style tags. So they can't use tsx extension and requires separate ide plugin based on Volar (the same tech used for Vue templating support)
Always Tailwind (Composition) over CSS (Inheritance). You cannot write tailwind without knowing CSS in the first place. You’ll be better at Tailwind by watching 20 min CSS video instead of a 4 hour Tailwind tutorial, that’s the reality.
46:04 I think this example is something you would almost never see and should generally avoided. However, I can understand why you would want to reverse nest to encapsulate something like that class for it to be the main contextual focal point, or locus of control. Can't think of many scenarios where you do that though. I never have.
I've been a web developer since the late 90s. I still feel like the simplest solution is usually the best. For example, I don't use a framework unless I'm building something that requires a ton of interactive elements. Vanilla HTML/CSS/JS works very well for small websites. When I do use a front-end framework I've never used a meta-framework like Nuxt or Next. They simply add more garbage that I don't need or will never use. It's easy to keep a project organized without adding complexity.
One day, my friend spoke at a conference telling how to effectively query a database. I said that his speech was for interns because without this knowledge you can’t even get a job, let alone write the backend. He replied that most in the room did not know about it. More than 10 years have passed since that moment and now I accept the fact that a backend developer may not even know sql. When you say that most React Apps are “ok”, you need to clarify that the limit of “ok” lies in accepting that their html is not even valid.
I'm tired of people like me complaining about how the kids do it today. I am sick of people who were there for CSS at the beginning telling the kids they are doing it wrong when the kids are running circles around us.
Yeah, it's like "I built a web-application that can pull data from 4 sources in 3 different languages in real-time, implemented a cache layer that keeps response times under 150ms and delivered a tree-shaken components bundle to the frontend that creates a websockets connection and updates in real-time while implementing bandwidth-saving measures for when the app is backgrounded or closed. This single codebase is also fully responsive for screens from 320px wide to 3840px and beyond and re-prioritises information based on the device type used to render it!" [Old timer] "Why is everything so complex. Just use PHP!"
we've had server side rendering since day 1. when content matters (seo, etc) -use robust server side rendering, do some jquery. when data sheningans matters -use client side react
Do any of you know which CMS Theo is referring to in his “all CMS platforms are bad” section? I have mixed feelings about the CMS solutions I have worked with. So if you know which platform he is referring two, or if you would highly recommend one, I would be happy to to know
16:11 USE NESTING! Seriously, people! I think you've been traumatised by specificity issues, but first of all we have selectors like `:where` now which give your selector a specificity of 0, so you can scope it and override it all you want, we are also going to get `@scope` across all major browsers soon. Second: it's actually rare to have specificity conflicts when you write your CSS with a graphic charter or a design system in mind and you don't rely blindly on the cascade. If you want something to be a certain style, then style it, don't put the style on the parent if you don't understand the implications. And use SCSS to group together the selectors and media queries which constitute a feature. Gee...
IMO depends on the context. If you're writing an SPA, then yes, writing one in jQuery would be supremely painful. If you're writing a traditionally server-side rendered app and want to add some functionality with JS (kind of, old-school way), React would be pretty horrible.
And then moaned about people using it in the context the prhase was created for to describe a process that the phrase describes. It's just a really stupid argument. No one is baffled by the idea that servers can serve code.
Honestly, Sass is all I need. I went through a phase using everything but proper css, but one of my seniors was always open to use the libraries but he stressed that I should actually learn how css works. best decision i've ever made
IMO, The big difference between Trad SSR vs React SSR is that before state used to be inferred by reading the DOM. Now there state can be seemlessly handed over between server & client.
Probably a proxy. Easiest way to load analytics around blockers is to load the script from your own server under a randomly generated filename. Those scripts sometimes reference other scripts which you also need to proxy and rewrite the URLs for before loading them in the browser.
Is server-side rendering javascript really the hill Theo chooses to die on? Can any real engineer look at the glorious performance of 200 page renders per second and not feel a serious degree of hatred and contempt?
To be honest about the nesting topic. I worked at a pretty huge white label e-commerce application that had such code. So I actually saw that. That was 5 years and to be more honest it is only slowly dying out under the rewritten application. There are still deployments running that shitty code. Only good thing... We are not touching it anymore.
53:10 - I mean, can't we use the same argument against React? In the end, it's all just syntactic sugar around JS events and DOM API. Let's have a VS Code macro that would transform JSX (or whatever) into a nice stack of DOM API calls and `addEventListener`s.
I think you are selling the video short a little. I don't think that I would have gotten as much out of the video that you thought you were going to make. The way that you go back and forth with agreeing and disagreeing with his points (and your subsequent arguments) is far more enlightening.
"Who the * are you talking to that's suggesting Drupal, Apache, containerized Node and Web Components?!" 39:20 👋😅I'm the person. It wasn't by choice it was by necessity. Your career in enterprise consists of holding your nose and picking the best solution from a pool of terrible options.
Oh no, I thought it was an understatement that modern web devs don't know how to hide stuff with css until Theo did a 5 minute rant confirming that he doesn't know how to do it without tailwind 😅
"React popularized the idea of a component that owns its concerns" WTF is Theo talking about here? Yes, React popularized the idea of a component that owns its concerns... in the HTML/Javascript world. Components that owned their concerns is how people have been writing UIs in more traditional desktop application since basically forever (how reacts differs from these is its unidirectional data flow instead of the use of signals and slots). You are basically proving the author's point that javascript soy-devs deny the history and contributions that other technologies have brought.
56:00 WTAF?!?!?!?!? Programming languages and frameworks for the past 50 years have had this! QT? since the 90s. GTK? since the 90s. And ofc earlier exaples exist. And this is supremely easy in vanilla JS.
The (Theo's) CMS take is weird and ignorant. The really smart guys are less patronizing, more humble and striving for more viewpoints. What I see here is more religion than tech/science talk.
Yeah. Most clients wouldn't accept a build where every change has to go through you (even if that's what ends up happening 95% of the time). So being able to manage that content is pretty important for clients. Obviously the page-builder trend is very shit, but the core concept of CMS is sound.
The whole goal of CSS is reusing classes.. I'm a designer with front-end experience… And I believe CSS is much better than the tailwind solutions. But the problem is, designers and developers are not communicating enough to making and keeping a good system that’s minimalistic and reusable. - To make a comparison it feels like writing javascript and with repeating code that should have been a class or separate function
Sigh. React did not invent the notion of a self contained (owns it concerns) UI component. Been a thing since the early 90s. Also, I would argue that the percentage of React apps that are fine is in fact quite smaller than is suggested here. The main issue is that so many web applications would be so much better as mostly static content with the right sprinkle of interactivity. Nobody goes to the McMaster Carr site and says "Wow, this shouldn't use path-based navigation and a static set of filters for each page, how inflexible". It just works. And frameworks do such a poor job of letting you evolve those sites into full on interactive web applications in an incremental fashion without some massive rewrite having to occur. And that's just a pain.
I always say the analogy: You can put a nail in a wall with pliers, back of drills, but there is a reason the hammer exists. Same for this area. Imo JavaScript should remain client side. It was built for that, and nothing's wrong with that. Server side should use things that were specifically built for that. In those you have auth and security built in, proper session management, database management etc. For me JS on servers feels a bit glued together and clunky for me. Sure you can do it, but as I've used both for servers, I think a server centric language is better and easier. (I understand that as a Java and Kotlin developer I'm most likely biased. But I do use JS, but for clients. You can rant me, but this is personal opinion. Feel free to say your opinion too, but keep it respectful)
The argument against nesting is weird. In my opinion, CSS nesting enables you to write better cascades and better scope your components. Sure, you _can_ go overboard with it, but IMO things like .card { header { … } footer { … } } work well.
The whole goal of CSS is reusing classes.. I'm a designer with front-end experience… And I believe CSS is much better than the tailwind solutions. But the problem is, designers and developers are not communicating enough to making and keeping a good system that’s minimalistic and reusable.
8:03 In the spirit of the original post... well fucking done! I've been living this nightmare for nearly 30 years. Not only do we, as devs, need to fully understand context... in 90% of cases, we're almost always the only ones in a dev-ops environment, 'scuse the oxy-moron, that actually understands the process at all, other than those "bottom end diamond users" that actually work for a living.... The facts is, ops couldn't produce a set of requirements if you paid them. Unless you're in some sort of very dangerous engineering discipline where mistakes are not an option. I speak from experience when I say you can literally spend tens of millions of £or $s on a project run by operations, where all the code and documentation is produced by one dev in just a few months. from a grumpy old dev that spent most of his career in banking and bat-shit crazy engineering 🤐😢
I definitely don't think frameworks are the worst part of frontend development. I do think many frontend devs use entirely too many dependencies with little-to-no value and often duplicative functions.
My preferred tech stack is 38 years old, and it's more reliable, more performant than anything the zoomer devs of today are using. They just do not care what is actually good if it's old.
Am I the only one who thinks doing show on hover thing in plain CSS is actually not just simpler than doing it in JS but *far* simpler. Maybe I am just spoiled with modern CSS and don't have enough experience with JS because I have a headache thinking how I would implement it in JS considering the pointer API edge cases
The bad thing about React is that it takes over everything and doesn't play nicely with others. HTMX and Web Components FTW! I do agree that React is ideal in certain situations. But most apps don't require the complexity that it brings to your front end.
Java Server Faces had capability to render partials on server and send them as update (similarly to HTMX) thru XMLHttpRequest. That was around 2010. I myself have written a small JS lib in 2004 that fetched small HTML snippets from PHP and updated a div's innerHtml. That was in IE6 days...
I did that too. Basically ended up invent component system and mini framework on my own where I can put properties in http request and server render the right html element according to props. Never want to do that again. So glad we have proper tools now.
BEM and similar naming conventions are lousy AF. Naming should be like chaining semantic tags, with different functions (nothing to do with styles) for concatenated segments of the chain.
1. I didn't realize people didn't care about semantic HTML. I'm obsessed with it. 2. I have to disagree with you Theo, I agree with this writer. If your app is that big, the company should hire a front-end architect to design these systems and naming conventions. Tailwind is a fine solution, but it still has it's downsides. Named classes are very nice for understanding your code while reading it, and debugging your code. That being said, the writer feels a bit egotistical and arrogant.
honestly, if everybody takes the approach: we should use react you would do more positive than negative, I'm working on an ejs project where for everything you juwt gotta know it... how is this function deifned? search through codebase, where is this functiondefined? same, how do I do X, global function you just gotta know. Where does this data come from? ah, 2 ids where 1 steals from the other, why does the dialog not close? it respects bootstrap docs wtf? yeah... most companys would have a net benefit from react I'm sorry if you got forced into it, but ther other side is praying that webcomponents will do the trick because oh lord adding a bundler to a 7GB project.....
Everything you keep saying you can't do with the jquery way, can easily be done. I can do everything you can do in react with jquery and javascript but without compiling. It does take the extra work to organize your code, setup classes and methods as wrappers or helpers, but to your argument, that's what react does by default. That's really what react is, a bunch of helpers condensed into a new way of doing things. I think the author is correct in saying that things are going in the wrong direction and making things bloated and more complex, when a different route could have been taken where we don't need a giant framework that requires compiling. I think he has what he's trying to get across on the tip of his tongue but lacks the expertise to express what he's feeling. I'm thinking I might take a shot at writing a blog post one of these days, but do it right, about the same topic. It won't be one sided either, it will explore the pros and cons of both sides of this argument. Seems pointless to write though, use react, write your own libraries and use jquery, doesn't matter, if you have good coders both ways can be amazing and they can both be complete crap with bad developers. To each their own.
I am the author of the the article in question, and I think that this issue of jQuery is the most misunderstood part because "jQuery" is now a trigger word for developers. All code experiences entropy. All code gets worse over time. jQuery, as a tool, is "simple' in that it is composed of few parts. Complex is being composed of many parts. jQuery, being a single "part", provides a simple (not-many-parted) solution to a simple problem. What Theo completely missed in taking my example and doing it in React is that he made it more complex (made more parts). Beyond the literal composition of code, he had a React environment and all that entailed (NPM et.al.) - jQuery would've only required a script tag. Theo then decided to take the jQuery example into a scalability question to then justify a React-ish solution, which again misunderstands the basic problem of: get data, do a single thing on the page with data. This misrepresents the problem because not every problem is "It needs to be a SPA". Sometimes you just need a little data and an update.
@@paceaux I understood what you were trying to get across, although who knows who else did. I've done both react and jquery, both recently. Personally, I prefer to use a little js framework I wrote, that does a lot of what react does but without compiling. It's simple, organized, solves most developer issues, gives you full control over everything, and with my helpers it's a lot less code. I see the reason to use react, but I find there are a lot of issues. First, you have to compile code for a font end language, which makes debugging much more difficult no matter what tools you use. If there is an error in test.js on line 46, I can fix that very easily. I'm also working in a react app built by someone else, and it's just as sloppy as any js app I've ever worked in. Back to my main point though, both are fine, just depends on who's code you're working with. I could release my framework out into the wild, and I know for a fact there are a ton more like mine out there, but it's not worth it. I don't have time to maintain it, keep adding to it, write professional documentation for it, make it perfect, etc.. I use it to get stuff done fast, and it's far from perfect, but it does keep things super simple. There's nothing you can do in react I can't do in mine. Maybe if I were funded to do it, but it's not going to have a return on investment, so it's not going to get funded. Basically, there's many frameworks in the world that make react look silly, but they will never see the light of day. As for CSS, there's really no way to make it better, it's messy, hard to organize, but it gets the job done. Tailwind solves some issues, but again I could go either way. I'm fine doing things in basic css, and the overhead of running tailwind doesn't seem worth it to me. But maybe for the right project it might be worth it. I think the big issue is a lot of developers have a bunch of stuff in their css that's never used, never cleaned up, and it's a giant mess, and they keep overwriting classes with new ones because it's easier than fixing what's currently there, causing complete chaos.
a while back i switch to using svelte cause it obviously has a lot of things going for it, and initially seems to have a simpler model and "cleaner" code base. After working on it for a while and attempting to create data table component that can take custom renderers for the columns you start running into issues, in react, its just a function that you pass or a element that you can clone content into. many ways to handle this use case. while you can still do it svelte, passing custom rendering to a component is still really crappy dev experience and felt foreign even to svelte. apart from this the svelte files with script tags, and custom rules for what gets exported from a svelte file and types etc. in react its just es modules at the end of the day. same rules as any other files. as much as i hate certain things about react, you cant fucking beat it because it works and it works REALLY fucking well, and for the small range of cases where its poor, you can always work around it. can't beat the GOAT
ChatGPT, summarise this video into a paragraph.
The author is frustrated with modern frontend development, saying it has become too complicated with tools like React, Tailwind, and JavaScript-heavy setups. They believe simpler methods, like old-school jQuery or basic server-side rendering, are often better and easier to manage. They think developers focus too much on trendy tools instead of keeping things simple and practical. The author wants people to prioritize straightforward solutions and only use modern frameworks when truly necessary.
@@mortenhauan love you for this 😂
@@mortenhauan Valid
@mortenhauan
Is it really that complex? Choosing react for everything isn't a js issue it's a team leadership issue. Don't blame react for poor leadership decisions.
@@mortenhauan As the author of the article, that's it in a nutshell with a minor correction:
It's not that I think jQuery or "traditional" SSR is better. It's that they are less-complex solutions, and I think we need to prioritize the least-complex solution for the problem.
Theo completely doesn't grok the point I made about jQuery at all because he was too triggered by the mention of it.
This guys blog post is completely incomprehensible to Devs who have had the luxury of never being forced to wade into the truly horrific and utterly sadistic enterprise and/or outsourced codebases that are literally decades old. I understand every word of what that guy was saying even if I knew he was off-base in a lot of it because that dude has simply never seen a codebase written in javascript that wasn't a complete and utter disaster zone the likes of which I guarantee you 80%+ of the people reading this can't even comprehend. It's literally soul-sucking, I've been forced to work with code that gave people clinical depression, and unnecessary Javascript & build tools multiplied an already miserable experience by maybe 3 to 4 times what it was.
The only proper response to that guy's post is pity and the kind of support you'd offer to someone who's standing on the edge of a cliff. Who cares about their bad takes on jQuery bro this is literally a cry for help.
Same with php and js... Working in a custom CMS, a small company, no types no docs pure suffering and pain... NOT EVEN GIT... LIKE WE ARE FORCED TO WORK WITH FTP AHHHHHHH
@jabbruh I've been encouraged to work with FTP exactly once, in college, and I never touched FTP more than a handful of times. That was almost exactly the same time I started watching Prime, and decided (for no particular reason) to learn vim and HTMX. Simply SSHing into the server and learning to use vim while simultaneously learning webdev and modifying the assignments to work with HTMX was _much_ easier than the headache I just _knew_ trying to fiddle with semantic versioning and FTP would be. And that was all solo project stuff, I can't even _begin_ to imagine how bad working on a _team_ and fiddling with that stuff would be!
You make far too large an assumption about the dude. You don’t know anything about the persons work history. Everything else is fair.
"...when you didn't write them, and can't control them"
Coding with AI editors will only amplify this issue. AI loves to generate hundreds of unnecessary lines of code, and the new no-code natural language movement will lead to an unimaginable quantity of software bloat. But what do I know anyway, I am just a react dev who uses Cursor too.
uh, it has improved quite a lot. I haven't used copilot for a few months and this week I fixed so many bugs in 1-take. It's also updated and pretty much connected to internet so i'm not sure the argument of "ai spitting out unnecessary lines" holds up. Let's be honest. AI will do it all, you won't need to write code. 🤣
1:14:58
No, you don't need to make 3 copies of the same method. You can just put a data-attribute on the HTML button element and then read that in the method. It's a class selector, and not an ID selector for a reason. You may dislike that, but it's in fact very similar to putting props on a React component.
That's the way I'd do it.
Where does the data-attribute come from? How do you make sure it's globally unique (answer: you can't).
This might not be an issue in small code bases, it all depends on what you're working on.
Most likely you would just put the data attribute onto the button element when rendering HTML on the server.
In this example you would just do something like:
const id = $(this).data('id');
inside the class selector. In this particular use case the data-attribute doesn’t need to be globally unique, but admittedly the class does.
Yeah, it’s definitely something that becomes an issue on large codebases with many devs. I like React and similar frameworks for larger projects with a lot of interactivity.
The author clearly stuck in a phase of "what I used to do is simple. What come after that is adding complexity".
I lost it when author show JQuery syntax with a lot of $ sign and weird JSON and say "see how simple it is?".
I can read that very easy today. But I still remember the first day I learn about JQuery with similar example and I was like what the hell is this dollar shit. What the hell is Ajax? What the hell is a soccer club in Netherland have anything to do with web development. And what the hell is () => { }. And why does this thing does not execute in order? etc etc. This is not simple, readable and intuitive at all.
That JQuery code is simple to the author just because he has been in the space way too deep. It is not inherently simple.
There is an inherent complexity that come from badly design technology. But author seems to not able to differentiate that from simply something he does not know. Like, LISP and Haskell is simple once you understand it but takes time to learn. On the other hand BASIC programming language back in the day with GOTO is really easy to learn and grab at first glance but get complex real quick.
Author seems to think like "everything I know is simple. Everything I don't know (or know but don’t use as much) is unnecessary complexity".
everything is simple and easy when you know..
I agree so hard.
I've worked with vanilla JS for 90% of my career. I am a freelancer who specializes in pagespeed opitmization, so using Jquery is completley unjustifiable to me. You don't need any of the abstractions Jquery offers, just like you don't need abstractions that React offers, but I think the author is more comfortable with Jquery than React, so he sees Jquery through rose colored lesnses.
I am very surprised that Theo never said the word "declarative" at that point in the video. I have worked in crazy complex imperative jQuery code. The best part of React (over jquery) is components having a declarative pattern.
Complexity comes from having lots of uncontained state on the front end. MPAs are extremely simple because the DB owns the state. Now, MPAs are not ideal for everything, like when you have truly heavy state on the front end. But many times developers think they have a lot of state but don't realize starting with the SPA mindset causes there to be way more state then should have been there to begin with.
Yes! I am a 2023 graduate who wrote their first line of code in 2018. Back then we had a web development course with Laravel and PHP. Seeing the syntax and ecosystem was very difficult to grasp and I barely understood anything. So much so that for the next 2-years I swore I'd never be a web developer. Life has a certain humorous irony as since then I've become fullstack RestAPI web developer with all kinds of tech stacks. Comparing my code and diary notes then to now is entertaining in how much has changed in such a short span of time and how far I've gotten from those early days. Now reading PHP is like reading a native language and everything is just so logical, clear and obvious. But that's exactly why professionally exposure and experience is so important so that you learn.
30:20 how would that be hard with regular css? Like .parent-class:hover .button-container { display: flex; }. Am I missing something🤔
Correct
You forgot iOS and iPadOS... But there are two solutions. You can either use the hover media query to use hover only on devices that support it and use JS for other devices. Or you can add the onclick attribute without value to the body element. Then also iOS and iPadOS support :hover. This sounds like a joke, but it's not. Sometimes Safari is the new Internet Explorer. You can also use :active if you add the tabIndex attribute to the wrapper element.
In my experience a lot of frontend developers do not know CSS, they know how to style a specific item, but not a whole page. dealing with !importants sucks for sure, it is why i do recommend tailwind, since it is scoped just to itself overall, it makes things much easier overall, and being able to extend it for your style is awesome. I know ive seen pages with multiples of the same class doing ther same thing, and the same class doing different things, both sucks. CSS is definitely not as simple as people think, but it is also quite amazing what it can do with such simplistic rules
CSS @scope and @layer makes life so much easier.
article stated reading time: 14 minutes
checks video length: 1:25:59
closes tab.
I tried hard to find 'Being "Early" Is Hurting Your Career' the screen shot says 1 day ago.
I fiund it 5 month ago with different title an other imager.
Currently ist called: 'Stop Using new tech (seriously)'
8:31 Ugh, this is why I have to leave the tech world (or start my own company). Leaders believing that it REALLY matters that an engineer cares about their product.
1. Products generally aren't difficult to understand.
2. Humans have most things figured out already and most humans wouldn't need to work. 95% of software engineering (and even more managing those products) is busy work.
Believing that people have to deeply care about a product to not only understand it but also deliver great results is insane. Born out of some weird management cult mentality that took hold of the tech world what seems to me a few years ago. At least around 10 years ago, it was largely still OK to just want to earn an income and enjoy creating things by writing code.
What you do have to do is care a little. (And take pride in your work. Which, admittedly, few seem to do these days.) You can still think that the product is a steaming pile of garbage but try to make the best out of it for the sake of the users. And because you're getting paid for it!
There are backend engineers who think there's no real engineering in the frontend.
I admit, I was kind of like that back when I was a backend developer (mostly Java). I didn't think frontend developers were "real developers" and I wasn't alone in that kind of thinking. Every backend developer I worked with had an ego problem. Now, I cringe when thinking about some of the conversations I had with team members.
my advice is: choose 1 framework and stick with it. It is no different than the others and you save a lot of time. I started with react in a bootcamp, learned nextjs after and thats it. Maybe theres a new framework that is 10% better and blablabla I dont care, I just use what I know and works
And most people do. There's a reason React is used on 90% of the project. "New framework every week" is just a meme.
@@IvanRandomDude Indeed. The minority are the loud people who have the fear of missing out. The "front-end problems" are not unique to front-end. It just happens that more people are doing front-end, and naturally you will have more voicing opinions about it while others do actual work.
@@dealloc i mean everybody knows that early adoption is a bitch, it's all fine and dandy until you start to notice the limitations of the new framework and 0 docs or help online because you just jumped at it. Best way to really know if new frameworks are actually better for you is doing some side project
every Framework is more or less the same except react which is objectively worse.
The stress i get from this image is crazy 💀 Most of the time right before i give up on a solution i worked for hours, it is most of the time resolved by a work that should have taken only 2 minutes 52:30
The text highlighting in dark mode is funny as 😂
I principle in naming CSS class name simple, just use random characters or with short characters (3 to 8 characters) this way it will not added to the output side of the page and css file. literally front-end devs can just inspect/search that class name and they will just understand.
As the author of the article, I definitely appreciate the promotion.
But a few things that should be mentioned:
1. My experience is almost exclusively in content management. Theo's experience isn't. We've had different careers and that explains much of our differences in perspectives.
2. Theo calling an accessibility bug on my site a "CSS skill issue" demonstrates his immaturity as a developer: he'd rather choose an ad hominem argument (attacking my character / person) than simply labeling the issue as a mistake. Which it was. Bugs are bugs; there's no need to insult people for them.
3. Theo only knows what he read in that article. He didn't read the other articles where I:
Provide naming conventions for front-end code
Describe in detail the problems with nesting, both in and out of Sass
Go over different problems front-end developers experience in content management scenarios
Explain how to debug CSS
Explain how CSS Specificity works
Explain how the CSSOM works
Explain how to read a CSS Selector
Explain how an em is computed
Explain CSS 4 fonts
Explain how to write CSS for a CMS
He only had an hour and a half, so I don't fault a guy for doing the best he can with the resources he had.
Thanks, Theo, for the promotion. Feel free to reach out to me if you want to continue the discussion.
On 2: The CSS skill issue point is an illustration of why you can't just ask people to _for god's sake use the platform_. Mistakes happen; and there are ways to eliminate whole classes of mistakes which you are dismissing without enough justification (Tailwind is just a good set of utility CSS classes and build-time / IDE-stage tools to automate that).
On that note, "immaturity" is a far worse personal insult than "skill issue" / "'clearly doesn't know CSS' ... so I guess writing your own CSS doesn't make everything better".
As a reader / audience member (edit: and someone with far less frontend experience) I do look forward to more discussion though, if that could happen.
More on the skill issue point: 40:34
Explaining tech to non-tech people is a situation where there are two approaches to make it easier: change the stack to make it easier to explain, or get better at explaining it.
Doing styling correctly is the same: use whatever tools one knows of, or just get better at CSS.
Both options for both situations are sometimes valid. But the article is discrediting valid tools because people should just learn to do it right while still showcasing there are limits to skills. This is, I think, why he said "if the author's going to skill issue me I'm going to skill issue back".
Also, 1:19:30.
To be honest, Theo has always been like in point #2, lots of ad hominems and other sorts of churlish insults in many of the other videos he makes. It's just the sort of content I'd expect from him these days as he seems incapable of critiquing something fairly if he doesn't have first hand experience with it.
How the hell did you list a bunch of blogs about how to deal with the insanity of CSS and then say with a straight face "Quit acting like CSS is some giant-ass mistake that needs fixing... They didn’t make mistakes". You realize the W3C CSS Working Group literally has an article called "Incomplete List of Mistakes in the Design of CSS" with FOURTY EIGHT bullet points? Even the official working group doesn't sniff their own farts, but don't let that stop you. "Just… grow up and think."
For me CSS is not hard at all, just write the name of the component in the class and you are good, much harder to deal with tailwind edge cases.
And don't forget we have css layers now
Wish we had layers in s, grumble grumble.
"I create my own content."
*proceeds to read someone else's content*
Commentary is content! Bring DVD audio commentary tracks back!
I mean he just read my blog post to like 10k+ people so I guess I'm not mad?
@paceaux I imagine you wouldn't be, I just find the juxtaposition of that statement followed by him doing that kind of amusing. 😅
React content is bottom of the barrel content. Easy to put out since you don't really have to do anything creative yourself, just give a few quips and opinions on other peoples stuff.
The thing is: people gobble this shit up and watch it, so thats why its popular. If it didn't get views and thus money creators wouldn't do it. So in reality its not really creators faults, its what viewers ask for.
Go into any youtube comment section or twitch chat and you'll see people begging them to react to something.
well, the amount of his own commentary is massive
"I'm still relatively new to Frontend, I started in 2018." 2018, 2019, 2020, 2021, 2022, 2023, 2024. Bluds been doing frontend longer than I have been doing applications, graphics, and games programming. (3 years.)
Thanks for the reaction. Seeing you React Andying anytime it's slightly criticized is the reason I'm subbed for.
New dev here, what is Theo talking about here 53:31 with pre-commit hooks and ides? is he talking about an extension to run the pre-commit hooks or something else?
You got it wrong...
"The 2 hard problems in computer science are:
1. Cache invalidation
2. Naming things.
3. Off-by-one errors.
"
Naming things isn't difficult with AI
The jQuery section cracked me up, honestly thought it was a joke at first when the article mentioned it has everything 😅
Dont understand when people say things have gotten sooo complex.
Im using react, tailwind, tanstack router and tanstack query for a legal case management system im building.
Bruh just make an api call wrap it in useQuery render the data. Add bg-blue-600 to the button move on lol
3:20 i cant find a single video shown here listed on your channel...
it's not the same channel like this one, it's @theorants
5 months ago
yes you can. the video was just recorded like 5 months ago
1:03:54 holy shit fuck everything about that statement. jQuery is such a pain in the ass I still prefer using 10 lines of native JS to writing out a single line containing jQuery. I disagreed a ton before now, but this was my breaking point.
I agree with a lot of what he wrote in the article and kudos to him! Finally people are beginning to say it lol! 😂 As soon as we got front-end "react Andies" js is used everywhere now even in many places where it shouldn't. Also, I do agree with the point that it's nice when the same language is used for a full stack but I chose something other than JS... Soon people wouldn't need js for the client side work is already on its way in that segment...
25:00 I mean maybe specific *termization* with the abbreviation, Server-Side Rendering (SSR), didn't exist but we've definitely been saying it was "rendered on the server" for a long time. I'm glad the recent 'industry term' is intuitive where people can be anachronistic with it, and I don't think conflating the term with the reality is that big a hit to their arguments...
I‘m wondering if you could count Server Side Includes (with Apache) as an early form of SSR🤔
48:00 - "I never liked the idea of generating classes based on a set of values"
Theo, you've *just* been praising Tailwind, what on Pluto are you talking about?
33:00 Astro is not jsx, they have their own compiler. I tried using Astro but immediately hit compiler bugs 30 minutes in, tooling around real jsx is flawless.
28:20 - I'm sorry but I kinda chuckled over the whole "group" thing in Tailwind.
That moment when Tailwind realizes you need cascade, so it has to emulate it. 😂
29:00 - but the apperance and disappearance of the buttons is not part of the markup content, it is just a concern of presentation. The fact that the buttons are hidden and are only appearing when their parent is hovered should not even be part of the markup at all. Even from an accessibility standpoint this is plain wrong. The buttons are and should de-facto be always there, execept if you want to make even the keyboard navigation to these buttons modal. The fact they are invisible and reappear are part of the presentation, not of the content and it should not even concern you when writing the markup.
45:50 "I've never seen this behavior actually being written before" I've actually written that behavior before. Usually only in the context of 'this component behaves differently if its a child of this other component' or 'this has a different feature-attribute-flag on the parent'. Every case is to keep the styles altering the component in the Scss/Less file for that component and 90% of the time the nesting stops at that level.
7-day free trail, what are we robots?
G2i engineer here, we receive for those days, G2i probably doesn't charge the company that hires with them.
@eduwric well if they are getting paid then it's fine 👍
Just to nit on details: Astro is not JSX (but Qwik and Solid are for example). Astro is JSX-like, but has more html-frendly exceptions, like you can't use jsx templating inside scripts or style tags. So they can't use tsx extension and requires separate ide plugin based on Volar (the same tech used for Vue templating support)
Big part of why solid and qwik use JSX is precisely because they can get ide support for free (or typescript support)
Always Tailwind (Composition) over CSS (Inheritance). You cannot write tailwind without knowing CSS in the first place. You’ll be better at Tailwind by watching 20 min CSS video instead of a 4 hour Tailwind tutorial, that’s the reality.
46:04 I think this example is something you would almost never see and should generally avoided. However, I can understand why you would want to reverse nest to encapsulate something like that class for it to be the main contextual focal point, or locus of control. Can't think of many scenarios where you do that though. I never have.
1:16:00 Theo’s last React version is potentially vulnerable to cross-site scripting (XSS) attacks, if user could influence the content of `foo` param.
I've been a web developer since the late 90s. I still feel like the simplest solution is usually the best. For example, I don't use a framework unless I'm building something that requires a ton of interactive elements. Vanilla HTML/CSS/JS works very well for small websites. When I do use a front-end framework I've never used a meta-framework like Nuxt or Next. They simply add more garbage that I don't need or will never use. It's easy to keep a project organized without adding complexity.
One day, my friend spoke at a conference telling how to effectively query a database. I said that his speech was for interns because without this knowledge you can’t even get a job, let alone write the backend. He replied that most in the room did not know about it. More than 10 years have passed since that moment and now I accept the fact that a backend developer may not even know sql.
When you say that most React Apps are “ok”, you need to clarify that the limit of “ok” lies in accepting that their html is not even valid.
Can someone explain why 28:08 is difficult and not just div:hover button { display: block; } ?
Yeah that's what I was thinking about. Such a bad take
I'm tired of people like me complaining about how the kids do it today. I am sick of people who were there for CSS at the beginning telling the kids they are doing it wrong when the kids are running circles around us.
Yeah, it's like "I built a web-application that can pull data from 4 sources in 3 different languages in real-time, implemented a cache layer that keeps response times under 150ms and delivered a tree-shaken components bundle to the frontend that creates a websockets connection and updates in real-time while implementing bandwidth-saving measures for when the app is backgrounded or closed. This single codebase is also fully responsive for screens from 320px wide to 3840px and beyond and re-prioritises information based on the device type used to render it!"
[Old timer] "Why is everything so complex. Just use PHP!"
thanks for going through this as pushing back on the article still has a lot of value.
we've had server side rendering since day 1.
when content matters (seo, etc)
-use robust server side rendering, do some jquery.
when data sheningans matters
-use client side react
Do any of you know which CMS Theo is referring to in his “all CMS platforms are bad” section?
I have mixed feelings about the CMS solutions I have worked with. So if you know which platform he is referring two, or if you would highly recommend one, I would be happy to to know
31:10 "really efficient at wasting money and time" is now my favorite offence.
Note that Astro's templating *isn't* really JSX, they have their own compiler and language tooling
16:11 USE NESTING! Seriously, people! I think you've been traumatised by specificity issues, but first of all we have selectors like `:where` now which give your selector a specificity of 0, so you can scope it and override it all you want, we are also going to get `@scope` across all major browsers soon. Second: it's actually rare to have specificity conflicts when you write your CSS with a graphic charter or a design system in mind and you don't rely blindly on the cascade. If you want something to be a certain style, then style it, don't put the style on the parent if you don't understand the implications. And use SCSS to group together the selectors and media queries which constitute a feature.
Gee...
"relatively new to frontend" has been doing frontend for almost 7 years. what?
he said 2018, that was only about two or three years ago
@@alhazred3555 that was last month you mean right
@@alhazred3555 is this some inside joke that i'm not in on? o0
Lol, feels like it
I remember when we used tables for layout. 7 years? That's nothing.
The only sponsorship ads I watch from a RUclipsr is Theo period
Whoever thinks jquery code is better than react should be put on the first Starship to Mars never to return
Musk's potential clients🤣
IMO depends on the context.
If you're writing an SPA, then yes, writing one in jQuery would be supremely painful.
If you're writing a traditionally server-side rendered app and want to add some functionality with JS (kind of, old-school way), React would be pretty horrible.
he didn't say SSR "the term" was invented before javascript, he said server side rendered pages were not invented with javascript
And then moaned about people using it in the context the prhase was created for to describe a process that the phrase describes. It's just a really stupid argument. No one is baffled by the idea that servers can serve code.
Honestly, Sass is all I need. I went through a phase using everything but proper css, but one of my seniors was always open to use the libraries but he stressed that I should actually learn how css works. best decision i've ever made
IMO, The big difference between Trad SSR vs React SSR is that before state used to be inferred by reading the DOM. Now there state can be seemlessly handed over between server & client.
Amen for the "Content" rant. As a business major I care a great deal more about why than most software people and it's frustrating.
What was the function at 20:43 that helps analytics not to get eaten by ad blockers?
Probably a proxy. Easiest way to load analytics around blockers is to load the script from your own server under a randomly generated filename. Those scripts sometimes reference other scripts which you also need to proxy and rewrite the URLs for before loading them in the browser.
@floodlitworld thanks would look into it
Is server-side rendering javascript really the hill Theo chooses to die on? Can any real engineer look at the glorious performance of 200 page renders per second and not feel a serious degree of hatred and contempt?
To be honest about the nesting topic. I worked at a pretty huge white label e-commerce application that had such code. So I actually saw that. That was 5 years and to be more honest it is only slowly dying out under the rewritten application. There are still deployments running that shitty code. Only good thing... We are not touching it anymore.
14:17 the two hardest things in computer science are cache invalidation, naming things, and off by one errors.
This.
53:10 - I mean, can't we use the same argument against React? In the end, it's all just syntactic sugar around JS events and DOM API. Let's have a VS Code macro that would transform JSX (or whatever) into a nice stack of DOM API calls and `addEventListener`s.
I think you are selling the video short a little. I don't think that I would have gotten as much out of the video that you thought you were going to make. The way that you go back and forth with agreeing and disagreeing with his points (and your subsequent arguments) is far more enlightening.
"Who the * are you talking to that's suggesting Drupal, Apache, containerized Node and Web Components?!" 39:20 👋😅I'm the person. It wasn't by choice it was by necessity. Your career in enterprise consists of holding your nose and picking the best solution from a pool of terrible options.
You can make a great career capitalizing on other people's terrible choices.
Oh no, I thought it was an understatement that modern web devs don't know how to hide stuff with css until Theo did a 5 minute rant confirming that he doesn't know how to do it without tailwind 😅
"React popularized the idea of a component that owns its concerns"
WTF is Theo talking about here? Yes, React popularized the idea of a component that owns its concerns... in the HTML/Javascript world. Components that owned their concerns is how people have been writing UIs in more traditional desktop application since basically forever (how reacts differs from these is its unidirectional data flow instead of the use of signals and slots).
You are basically proving the author's point that javascript soy-devs deny the history and contributions that other technologies have brought.
How dare you show elements on hover. That’s terrible for accessibility.
56:00 WTAF?!?!?!?!? Programming languages and frameworks for the past 50 years have had this! QT? since the 90s. GTK? since the 90s. And ofc earlier exaples exist. And this is supremely easy in vanilla JS.
The (Theo's) CMS take is weird and ignorant. The really smart guys are less patronizing, more humble and striving for more viewpoints. What I see here is more religion than tech/science talk.
Yeah. Most clients wouldn't accept a build where every change has to go through you (even if that's what ends up happening 95% of the time). So being able to manage that content is pretty important for clients.
Obviously the page-builder trend is very shit, but the core concept of CMS is sound.
The whole goal of CSS is reusing classes.. I'm a designer with front-end experience… And I believe CSS is much better than the tailwind solutions. But the problem is, designers and developers are not communicating enough to making and keeping a good system that’s minimalistic and reusable.
-
To make a comparison it feels like writing javascript and with repeating code that should have been a class or separate function
Sigh. React did not invent the notion of a self contained (owns it concerns) UI component. Been a thing since the early 90s. Also, I would argue that the percentage of React apps that are fine is in fact quite smaller than is suggested here. The main issue is that so many web applications would be so much better as mostly static content with the right sprinkle of interactivity. Nobody goes to the McMaster Carr site and says "Wow, this shouldn't use path-based navigation and a static set of filters for each page, how inflexible". It just works.
And frameworks do such a poor job of letting you evolve those sites into full on interactive web applications in an incremental fashion without some massive rewrite having to occur. And that's just a pain.
I always say the analogy:
You can put a nail in a wall with pliers, back of drills, but there is a reason the hammer exists.
Same for this area. Imo JavaScript should remain client side. It was built for that, and nothing's wrong with that.
Server side should use things that were specifically built for that. In those you have auth and security built in, proper session management, database management etc. For me JS on servers feels a bit glued together and clunky for me. Sure you can do it, but as I've used both for servers, I think a server centric language is better and easier.
(I understand that as a Java and Kotlin developer I'm most likely biased. But I do use JS, but for clients. You can rant me, but this is personal opinion. Feel free to say your opinion too, but keep it respectful)
"Am I out of touch? No. It's the devs that are wrong."
The argument against nesting is weird. In my opinion, CSS nesting enables you to write better cascades and better scope your components. Sure, you _can_ go overboard with it, but IMO things like .card { header { … } footer { … } } work well.
when i see these kind of takes i'm very curious about type of projects and companies these people work at
The whole goal of CSS is reusing classes.. I'm a designer with front-end experience… And I believe CSS is much better than the tailwind solutions. But the problem is, designers and developers are not communicating enough to making and keeping a good system that’s minimalistic and reusable.
8:03 In the spirit of the original post... well fucking done! I've been living this nightmare for nearly 30 years. Not only do we, as devs, need to fully understand context... in 90% of cases, we're almost always the only ones in a dev-ops environment, 'scuse the oxy-moron, that actually understands the process at all, other than those "bottom end diamond users" that actually work for a living....
The facts is, ops couldn't produce a set of requirements if you paid them. Unless you're in some sort of very dangerous engineering discipline where mistakes are not an option. I speak from experience when I say you can literally spend tens of millions of £or $s on a project run by operations, where all the code and documentation is produced by one dev in just a few months.
from a grumpy old dev that spent most of his career in banking and bat-shit crazy engineering 🤐😢
I definitely don't think frameworks are the worst part of frontend development. I do think many frontend devs use entirely too many dependencies with little-to-no value and often duplicative functions.
My preferred tech stack is 38 years old, and it's more reliable, more performant than anything the zoomer devs of today are using. They just do not care what is actually good if it's old.
imagine how much worse the blog post on the topic would be if the author wasn't a frontend dev
53:45 I hate pre-commit hooks and husky. But I might be changing my mind a little about pre-push hooks.
Am I the only one who thinks doing show on hover thing in plain CSS is actually not just simpler than doing it in JS but *far* simpler. Maybe I am just spoiled with modern CSS and don't have enough experience with JS because I have a headache thinking how I would implement it in JS considering the pointer API edge cases
The bad thing about React is that it takes over everything and doesn't play nicely with others.
HTMX and Web Components FTW!
I do agree that React is ideal in certain situations. But most apps don't require the complexity that it brings to your front end.
Java Server Faces had capability to render partials on server and send them as update (similarly to HTMX) thru XMLHttpRequest. That was around 2010. I myself have written a small JS lib in 2004 that fetched small HTML snippets from PHP and updated a div's innerHtml. That was in IE6 days...
I did that too. Basically ended up invent component system and mini framework on my own where I can put properties in http request and server render the right html element according to props.
Never want to do that again. So glad we have proper tools now.
@@chakritlikitkhajorn8730 Exactly, this is where you find out that if you don't use framework, you end up writing your own without even knowing it 😀
BEM and similar naming conventions are lousy AF. Naming should be like chaining semantic tags, with different functions (nothing to do with styles) for concatenated segments of the chain.
I am so glad I don't have to think about BEM anymore.
“Relatively new” … “for 6 years”
This is legit black magic, you switched the site to light mode and my eyes hurt... even though my system is in light mode
1:07:23 Is the author still trying to setup webpack?
Webpack is too new, not production ready. He's setting up gulp
@PotravnyyVV 💀
Suggestion: put quotes around video titles like this, so I know at first glance it's not your take but it's someone's take that you're discussing.
So this author doesn’t like SCSS?
1. I didn't realize people didn't care about semantic HTML. I'm obsessed with it.
2. I have to disagree with you Theo, I agree with this writer. If your app is that big, the company should hire a front-end architect to design these systems and naming conventions. Tailwind is a fine solution, but it still has it's downsides. Named classes are very nice for understanding your code while reading it, and debugging your code.
That being said, the writer feels a bit egotistical and arrogant.
Ya you strike me as a back end specialist.
Who else remembers SSI?
"Reading time: 14 minutes"
Video: 1:25:59
Just wow
why are you not ranting on theo rants
Young man ranting over an old man shouting at a cloud. Are you not entertained?!
honestly, if everybody takes the approach: we should use react you would do more positive than negative, I'm working on an ejs project where for everything you juwt gotta know it... how is this function deifned? search through codebase, where is this functiondefined? same, how do I do X, global function you just gotta know. Where does this data come from? ah, 2 ids where 1 steals from the other, why does the dialog not close? it respects bootstrap docs wtf? yeah... most companys would have a net benefit from react I'm sorry if you got forced into it, but ther other side is praying that webcomponents will do the trick because oh lord adding a bundler to a 7GB project.....
Everything you keep saying you can't do with the jquery way, can easily be done. I can do everything you can do in react with jquery and javascript but without compiling. It does take the extra work to organize your code, setup classes and methods as wrappers or helpers, but to your argument, that's what react does by default. That's really what react is, a bunch of helpers condensed into a new way of doing things. I think the author is correct in saying that things are going in the wrong direction and making things bloated and more complex, when a different route could have been taken where we don't need a giant framework that requires compiling. I think he has what he's trying to get across on the tip of his tongue but lacks the expertise to express what he's feeling. I'm thinking I might take a shot at writing a blog post one of these days, but do it right, about the same topic. It won't be one sided either, it will explore the pros and cons of both sides of this argument. Seems pointless to write though, use react, write your own libraries and use jquery, doesn't matter, if you have good coders both ways can be amazing and they can both be complete crap with bad developers. To each their own.
I am the author of the the article in question, and I think that this issue of jQuery is the most misunderstood part because "jQuery" is now a trigger word for developers.
All code experiences entropy. All code gets worse over time.
jQuery, as a tool, is "simple' in that it is composed of few parts. Complex is being composed of many parts. jQuery, being a single "part", provides a simple (not-many-parted) solution to a simple problem.
What Theo completely missed in taking my example and doing it in React is that he made it more complex (made more parts). Beyond the literal composition of code, he had a React environment and all that entailed (NPM et.al.) - jQuery would've only required a script tag.
Theo then decided to take the jQuery example into a scalability question to then justify a React-ish solution, which again misunderstands the basic problem of: get data, do a single thing on the page with data. This misrepresents the problem because not every problem is "It needs to be a SPA". Sometimes you just need a little data and an update.
@@paceaux I understood what you were trying to get across, although who knows who else did. I've done both react and jquery, both recently. Personally, I prefer to use a little js framework I wrote, that does a lot of what react does but without compiling. It's simple, organized, solves most developer issues, gives you full control over everything, and with my helpers it's a lot less code. I see the reason to use react, but I find there are a lot of issues. First, you have to compile code for a font end language, which makes debugging much more difficult no matter what tools you use. If there is an error in test.js on line 46, I can fix that very easily. I'm also working in a react app built by someone else, and it's just as sloppy as any js app I've ever worked in.
Back to my main point though, both are fine, just depends on who's code you're working with. I could release my framework out into the wild, and I know for a fact there are a ton more like mine out there, but it's not worth it. I don't have time to maintain it, keep adding to it, write professional documentation for it, make it perfect, etc.. I use it to get stuff done fast, and it's far from perfect, but it does keep things super simple. There's nothing you can do in react I can't do in mine. Maybe if I were funded to do it, but it's not going to have a return on investment, so it's not going to get funded. Basically, there's many frameworks in the world that make react look silly, but they will never see the light of day.
As for CSS, there's really no way to make it better, it's messy, hard to organize, but it gets the job done. Tailwind solves some issues, but again I could go either way. I'm fine doing things in basic css, and the overhead of running tailwind doesn't seem worth it to me. But maybe for the right project it might be worth it. I think the big issue is a lot of developers have a bunch of stuff in their css that's never used, never cleaned up, and it's a giant mess, and they keep overwriting classes with new ones because it's easier than fixing what's currently there, causing complete chaos.
a while back i switch to using svelte cause it obviously has a lot of things going for it, and initially seems to have a simpler model and "cleaner" code base. After working on it for a while and attempting to create data table component that can take custom renderers for the columns you start running into issues, in react, its just a function that you pass or a element that you can clone content into. many ways to handle this use case.
while you can still do it svelte, passing custom rendering to a component is still really crappy dev experience and felt foreign even to svelte. apart from this the svelte files with script tags, and custom rules for what gets exported from a svelte file and types etc. in react its just es modules at the end of the day. same rules as any other files.
as much as i hate certain things about react, you cant fucking beat it because it works and it works REALLY fucking well, and for the small range of cases where its poor, you can always work around it. can't beat the GOAT
Genuine question. Are people still using jQuery in 2024?
If it's a smaller project where you need specific functionality, sure.
Talking from being in this position myself, people who say "X is shit!" often mean "X makes me feel like shit!"