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. 🤣
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.
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.
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)'
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.
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.
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.
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 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.
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
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?
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
"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.)
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
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."
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
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...
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.
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.
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.
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.
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.
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
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.
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?
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
"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.
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...
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.
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!
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.
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.
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)
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
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
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.
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.
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
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.
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...
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.
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)
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 😅
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.
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.
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.
"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.
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.
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.
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
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.
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.....
🤣 actually my main takeaway is exactly why i hate web development. It's the area of programming that encapsulates the XQCD commic about standards perfectly. Why the f*** is there 30 options to do every individual thing when 99% of projects aren't doing anything that complicated to begin with? Don't get me wrong specialized solutions get built everywhere, but they don't fucking publish them like they have the new bible for everyone else to use. And to make matters worse it's all syntactically flexible. So the same code will be written flipped by the next guy over. Nobody knows the actual rules well enough to teach them, they're just mimicking what they first saw and stating it's the "standard order we do here".
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. 🤣
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.
The text highlighting in dark mode is funny as 😂
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.
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)'
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.
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.
7-day free trail, what are we robots?
"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
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.
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.
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.
article stated reading time: 14 minutes
checks video length: 1:25:59
closes tab.
I‘m wondering if you could count Server Side Includes (with Apache) as an early form of SSR🤔
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?
The jQuery section cracked me up, honestly thought it was a joke at first when the article mentioned it has everything 😅
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
"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.)
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
Thanks for the reaction. Seeing you React Andying anytime it's slightly criticized is the reason I'm subbed for.
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."
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
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
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
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...
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.
"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.
Can someone explain why 28:08 is difficult and not just div:hover button { display: block; } ?
What was the function at 20:43 that helps analytics not to get eaten by ad blockers?
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.
How dare you show elements on hover. That’s terrible for accessibility.
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.
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.
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.
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
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.
The only sponsorship ads I watch from a UA-camr is Theo period
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?
"Am I out of touch? No. It's the devs that are wrong."
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
thanks for going through this as pushing back on the article still has a lot of value.
14:17 the two hardest things in computer science are cache invalidation, naming things, and off by one errors.
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.
"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.
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.
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...
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.
when i see these kind of takes i'm very curious about type of projects and companies these people work at
he didn't say SSR "the term" was invented before javascript, he said server side rendered pages were not invented with javascript
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!
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.
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.
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)
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
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
Who else remembers SSI?
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.
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.
Whoever thinks jquery code is better than react should be put on the first Starship to Mars never to return
Musk's potential clients🤣
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
31:10 "really efficient at wasting money and time" is now my favorite offence.
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.
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...
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.
This rant was made FIVE month ago. Geesh
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)
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 😅
imagine how much worse the blog post on the topic would be if the author wasn't a frontend dev
So this author doesn’t like SCSS?
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.
53:45 I hate pre-commit hooks and husky. But I might be changing my mind a little about pre-push hooks.
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.
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”
"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.
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 😀
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.
Ya you strike me as a back end specialist.
lier, you deleted the video about the new browser
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.
i was doing spa back in 2007, with jquery and php, it was just not call spa yet.
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
Theo learning jquery live on stream was not on my bingo card!
This is legit black magic, you switched the site to light mode and my eyes hurt... even though my system is in light mode
I'm surprised he didn't talk about TypeScript
"Reading time: 14 minutes"
Video: 1:25:59
Just wow
Genuine question. Are people still using jQuery in 2024?
If it's a smaller project where you need specific functionality, sure.
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.
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.....
OMG, I actually LoL'd at the jquery statement.
"and offset my one" was missing in the two most important problems ;-)
🤣 actually my main takeaway is exactly why i hate web development. It's the area of programming that encapsulates the XQCD commic about standards perfectly.
Why the f*** is there 30 options to do every individual thing when 99% of projects aren't doing anything that complicated to begin with? Don't get me wrong specialized solutions get built everywhere, but they don't fucking publish them like they have the new bible for everyone else to use.
And to make matters worse it's all syntactically flexible. So the same code will be written flipped by the next guy over. Nobody knows the actual rules well enough to teach them, they're just mimicking what they first saw and stating it's the "standard order we do here".
i never understand people complaining about video length like its assigned reading lmao. just....don't' watch ?
did the FEDs write this
Is this a real person or did someone give ChatGPT a prompt to have them impersonate your typical online "JS sucks" commenter?
I did not hear good things about IBM so idk...