I am a front-end developer who is FED up about front-end development. If you write front-end, this isn’t about you personally. It’s about how your choices make me angry. Also this is about how my choices have made me angry. Also this is mostly just about choices, the technologies are incidental.
Note: The views expressed in here are not those of my employer. They are (probably) the views of thousands of people just like me.
Warning: This article is filled with profanity. Ask your scrummaster if 8 points of profanity is too much to handle today.
First, some background
I have neither a computer science degree nor an engineering degree. But I have worked in web technologies since the second Bush administration. I’ve worked in a variety of roles ranging from business analyst, tester, all the way through developer, consultant, and principal architect.
I did agency work for 11 years before making the choice to work for a very large tech company. I have worked across sectors like insurance, healthcare, retail, banking, investing, marketing, and manufacturing. I have worked with global brands which are household names.
I have written a lot of front-end code for a lot of companies. I have also dealt with a lot of consequences created by front-end code. My criticisms come from my role as a front-end developer and as someone affected by a front-end developer.
No one gives a shit about content
Unless it’s a content-specialized front-end developer who works specifically in the content management space and is specialized in writing front-end for content management system. Did you count how many times I had to write both “front-end” and “content”? Too fucking many.
I have mentored quite a few bootcamp graduates. There are exactly zero graduates of zero bootcamps who have ever been told, “users go to websites for the content.” Zero. They all think it’s their moral imperative to make sure every site is built in React.
I have worked with exactly zero computer science graduates who have ever heard the phrase, “content before code”.
Unless the front-end developer has been forced by threat of not-being-able-to-pay-rent to care about content, they don’t fucking care.
This is wild to me because HTML5 semantics exist and their whole-ass raison d’être is, in fact, having an understanding of content.
- You can’t write content-managed HTML if you don’t understand the content.
- You can’t write semantic HTML if you don’t understand the content.
- You can’t write SEO-ready HTML without understanding the content.
- You can’t write accessible HTML without understanding the content.
- You can’t write good HTML without understanding the content.
Zero SPA developers that I’ve ever met have ever given a shit about using a <header> instead of a <section>. I have found NaN fucks given about using a p over a div. The number of times I’ve seen numbers written inside of a <li> that’s inside of a <ul> — instead of just using an <ol> — is deeply disturbing.
<ul> <li>1. Run this through an HTML Validator</li> <li>2. Weep publicly </li> </ul>
Maybe we should ask the designer or business owner a few questions about what the design means to the end-user before hammering out 18 layers of divs.
CSS is fine; you’re the problem
If someone gets a ticket for speeding, we don’t blame the car or the road. We definitely blame the idiot who thought it’d be a good idea to race the Dodge Charger camped out in the Dollar General parking lot.
It’s in this very same vein that we don’t blame CSS:
“The problem with CSS is that the scope is global”
Every dork who promotes writing styles in JavaScript
“The problem with CSS is the cascade”
“The problem with CSS is that it fails silently”
Those aren’t problems; they’re features. They are solutions to the very specific problems of, “how do we make content presentable as easily as possible, with as little duplication as possible, and with as few negative impacts to the user as possible.”
Chances are, the things you don’t like about CSS are the things you haven’t bothered to understand about it.
Styles rarely, if ever need to actually be scoped and encapsulated. In fact, the only time you want to prevent styles from being in the global scope is when you didn’t write them and can’t control them.
If duplicated class names are ruining your day, 15-class selectors are crapping in your cereal, and 8 !important are igniting turds in your garage, that’s actually an architecture problem.
Are there real problems in CSS? Of course. But those are problems like, “border-radius should have been called corner-radius,” and “atomic stacking contexts are generated when using opacity,” and “an em isn’t really an em.” Those are problems.
The C of CSS is not a problem. You’re the problem.
Put on your big-kid pants and develop a strategy, pick some conventions, write them down, and enforce them through merge requests and peer reviews.
Server-side rendering does not mean, “rendered with JavaScript”
There’s a disconcerting number of front-end developers out there who act like it wasn’t possible to generate HTML on a server prior to 20101. They talk about SSR only in the context of Node.js and seem to have no clue that people started working on this problem when season 5 of Seinfeld was on air2.
Server-side rendering was not invented with Node. What Node brought to the table was the convenience of writing your shitty div soup in the very same language that was invented in 10 days for the sole purpose of pissing off Java devs everywhere.
Server-side rendering means it’s rendered on the fucking server. You can do that with PHP, ASP, JSP, Ruby, Python, Perl, CGI, and hell, R. You can server-side render a page in Lua if you want.
Just because Node isn’t involved in generating HTML, that doesn’t mean it’s not possible to generate markup at request time. It is possible. It’s been possible. It will continue to be possible.
Stop denying the history, contributions, and value that other technologies bring to solving this exact problem that is definitely not unique to you.
JavaScript is not always the answer
My brothers and sisters in Christ I want you to know that I care about your souls enough to share these truths with you:
- You don’t need JavaScript to make a web page.
- You don’t need JavaScript to write styles.
- You don’t need JavaScript to make an animation.
- You don’t need JavaScript just to show content.
In 2010 I was a contractor for an organization working with some Very Smart IBM consultants. They could not figure out how our in-house developer made the navigation for the site they were implementing.
It was because our developer used CSS. Our consultants had never considered that CSS could do something as fancy as, “show you a thing when you hover over it.”
That’s a fun “har-har silly ignorant smart consultants,” story except at least it’s about their harmless ignorance.
It’s so much worse when they know JavaScript.
Five years ago I was on a project where the perfectly fine .net MVC app was turned into an API for delivering content to a .net core app that used node services to render Vue templates into fully rendered HTML which meant that all of our templates were written in Vue and we still had to write jQuery to make content interactive. We literally had two layers of JavaScript wrapped in a .net sandwich with JavaScript spread on the top.
I’m seeing architectures being proposed today that do pretty much the same thing I just described but with Drupal on Apache, containerized Node, and Web Components.
If making a peanut butter and jelly sandwich by spreading the jelly on both sides of the bread is disturbing to you, good. You can still find God.
Do you have any idea how frustrating it is that that in order to explain my sadness to my therapist I must first explain like 5 different technologies and by the time I’m finished she’s sad just hearing it, the session’s over, and I didn’t even get to what was making me upset? Technology has made my anger a recursive function.
Can we please stop adding complexity to our systems just so we can do it in JavaScript? If you can do it without JavaScript, you probably should. Tools shouldn’t add complexity.
Sass wasn’t just a mistake but a mistake factory
10 years ago I thought CSS preprocessors were the coolest thing ever and I was incredibly fucking dumb for thinking that.
The only three good features CSS preprocessors gave were
- Variables
- Mixins
- Color transformation
Every thing else was a mistake:
- Nesting
- Calc
- Functions, including control statements like if and for
- Interpolation
- Data types of any kind
- The entire module thing
Nested CSS obscures complexity
I hate this feature so much. I hate it more that it’s now native to CSS because not only has it spread, but it’s mutated 3. And not in a good, ninja-turtley way. 7
Nesting obscures complexity and then makes it impossible to find or fix.
Without using a compiler or psychedelic of any kind, can you tell me what this generates?
.feature {
color: blue;
&__header {
p & {
a {
&:hover,
&:focus {
color: red;
}
}
}
}
}
Does this seem reasonable to you?
.feature {
color: blue;
}
p .feature__header a:hover, p .feature__header a:focus {
color: red;
}
If that’s the output you expected, either you’re one of the Sass spec writers or you did a double-shot of espresso followed by a Ritalin chaser.
Nesting is not good. It hides the specificity that you’re producing and will lend to increasingly fragile code as you try to override a 13 part selector. It was useful for clumping pseudo-selector and pseudo-elements and after that it out-of-hand, making code that’s harder and harder to read, and even find in your codebase.
Interpolation, et all
This was also just a bad idea that we couldn’t have predicted at the time. I’m not mad at the Sass people for this. Hindsight is 20/20 and all. What I want is for it to all stop.
This is fundamentally a bad thing:
$sizes: 10px, 20px, 30px, 50px;
@each $size in $sizes {
.icon-#{$size} {
font-size: $size;
height: $size;
width: $size;
}
}
I know what you’re thinking.
You’re thinking, “But Frank, it saves me on keystrokes! Now I can generate more classes and classnames just based on that list of sizes!”
Bro.
ctrl+c and ctrl+v exist.
Are you a VS Code user? Even easier: Highlight it and press alt/opt + shift + ↓ , that’ll copy the chunk or line down. Then, highlight the part that’s repeated a few times (where you’d interpolate), press ctrl/cmd + d, and keep pressing until they’re all highlighted. Make your change. Now you’re done.
What did you save? Time and sanity in looking up the Sass syntax? Future time where future you is trying to find where the fuck .icon-80px is living? XKCD is not on your side for this automagical icon generator loop that’s going to piss you off with edge cases for the next 5 years.
Years ago I thought it was a great idea to create a mixin for CSS preprocessors to do my BEM stuff. It’s not. That removes traceability, which experience has taught me matters more than saved keystrokes.
Can we please stop using languages and tech stacks to solve problems that our IDEs are capable of helping us with?
Seriously … forget the Frameworks
I was blown away when Angular came out. It was an actual thing that could do it all. It could render the markup with fun logicy attributes, respond to data changes, make the AJAX requests, amazing! I wanted to use Angular for all the interactive web apps.
Then React came out. That was amazing. It could render the markup and … [incoherent mumbling] components or something… and … wait, that wasn’t even markup; it was JSX. Sure, I had to add a few libraries to really use it, but yay, I used it for interactive web apps.
Then there was Vue. Then Preact. Then Ember, Svelte, Backbone, Alpine, Mithril, Solid, Lit, Stencil, Qwik…
Maybe it’s because Angular was no one’s first choice — even though it came first. Maybe that’s why the front-end world lost its damned mind with React. React was so not-angulary that front-end folks were like, “let’s use it client side, server side, native-side, and the 3 other sides of a damned cube”. Folks decided it was a good idea to Reactify All The Things®.
And that’s how React, a framework used to deliver interactive content to a whole 28% of the world’s population, is being used to generate static sites.
I had a client a few years ago that was a household name. Their front-end was written in Gatsby. Gatsby is a static site generator that uses React. This globally-known brand had probably 50 websites in at least as many languages. But the content was very, very, static.
So imagine the horror the front-end dorks felt when they learned that a content author in Bulgaria updating the terms and conditions didn’t want the whole-ass site rebuilt for every country and language.
This would’ve been a non-problem had the web app been written in .net, Java, or, fuck me for saying it, PHP or Node.
But nah. These goobers got high off npm modules and did shots of JSX in the bathroom at lunch time. They chose a framework used to deliver interactive content to a significant percentage of the planet for generating non-interactive content on a server. It took them weeks to come up with a solution to the problem they created when they chose a problem as a solution.
Yes. I am absolutely calling React a problem. I’m calling Angular, Vue, and All the Rest of Them ™ a problem. Because unless you have a specific problem of highly interactive, data-driven content, you don’t need a framework.
You don’t need a framework to render static content to the end user. Stop creating complex solutions to simple problems
Also more generally fuck your complexity
This, more than anything, is a rant about complexity.
I am mad at how front-end developers create complex solutions to simple problems. I am mad that front-end developers use tools to obscure complexity. I am mad that front-end developers embrace complexity rather than challenge it.
You know what’s great about jQuery?
Everything.
jQuery took several complex problems (browsers do things differently, selecting elements is complex, changing things on elements is tedious, AJAX requests are a lot) and it provided a simple, intuitive, and readable solution:
$('.getResults').on('click', () => {
$.ajax({
url: '/api/results',
data: {
foo: 'bar'
},
success: function (result) {
$('.results').html(result);
}
});
});
Cool your jets for a second and think about how wonderfully simple that is. It handles finding your element in a way that lets you avoid the null checks, shortens your event binding, lets you make an AJAX request, lets you find the element that the result goes into, and plop it there if it’s successful.
If the problem is, “user clicks on thing, you get data, and show data”, that is a beautiful and simple 11-line solution. It did not need NPM modules and a build system.
And sure, maybe you don’t need jQuery, and that’s fine. Will you need more lines of code to do the same thing? Of course. But even without jQuery, your complexity doesn’t grow exponentially like it would if you brought in a framework with its build system, linters, compilers, and 700mb of Node Modules some of which inexplicably require some stupid shit like is-odd or is-git-url 4.
This is not an Old Man Shouts at Clouds moment where I want the world to go back to jQuery. This is me trying to illustrate how jQuery solved many problems with simplicity and somehow we seem to have forgotten the value of just being simple.
Pretend I’m not talking about JavaScript for a second. Let’s pretend it’s just an ordinary, everyday, 3-template web site. Maybe it’s managed by a CMS. Maybe it’s not. Does it really need Tailwind? Bootstrap? Even <gasp class=”from the back of the room”> Sass? Is writing plain CSS really such a terrible thought?
Let me fill you in on a cool fact about CSS: It doesn’t need a fucking compiler. No npm install -D sass. No npm i gulp. You get to tell WebPack to fuck off good and proper-like, the way the Good Lord Intended. 5
Simplicity is unsophisticated and lacking in many parts. The simplest solution to a problem is always the best solution. Choose simplicity. I’m begging you. Your future is begging you,.
Oh, and enough with the new and shiny
Sure it’s awesome that you can strongly type CSS variables, but that doesn’t mean you should 6. Can you have web components with declarative shadow DOM? d’uh! But, hear me out: Why have three steps to render markup when you could have one?
Yes, the new JS Framework is all the awesomeness. Definitely do a side project with it. Please in the name of her Sweet Saint Fuck of Apathy, don’t use it in your next project. We haven’t learned what our regrets will be, and the regrets are what everyone else has to live with but you.
I don’t care if it’s a new CSS trick, a new JS thing, or a new JS framework: Give it two years before you take it for a ride in production.
You know what happens in the next two years?
Two year’s worth of StackOverflow questions.
You do not want to be the person taking a new tech or feature for a joy-ride in production and discovering some hemorrhaging-edge bug.
You also don’t want to be the person who has to clean up after the person who discovered a bug on a bleeding-edge technology.
Person-Alpha is the asshole. The Alphasshole, if you will. Because they chose to use the bleeding edge thing.
On the scrum-master’s Fibionacci-sequence of suckassness The Alphasshole is a 21. The Alphasshole implemented the new tech and turned your project into a collection of medical-attention-needed polyps on Satan’s butthole.
Person-Beta is the Betasshole.
The Betasshole had to work in real-time with other betassholes on other projects created by other alphassholes that were all equally hemorrhoidal in nature over StackOverflow and Discord to come up with whatever collection of hackery that properly deserves to be called, “Satan’s Self-soothing salve of sour-ass solutions.”
The Betasshole is a 5 on the Satanic-sequence of Suckassness. They’re not nearly as bad as the dickweed who chose new tech. But unfortunately, they made a lot of terrible choices and cannot be free from blame, git-related, or otherwise.
Listen. I’ve been an Alphasshole and a Betasshole before. I regret that. I should not have done that.
I’ve also been gamma waaaaaay more often. Who is not an asshole. That’s a person who’s just had to deal with two years of shit rolling downstream. What’s unfortunate for the gammas is that they often will be accused of being the assholes because they will git-blame, complain, and refrain from touching whatever that new tech was because it’s haunted their nightmares and their daymares. They are simply picking up the pieces.
The new and shiny is fun for side projects. It is not for production.
Please put two years between you and any new tech. If for anyone, do it for the gammas who actually have to keep your precious world wide web running.
TL;DR
Just… grow up and think.
- Think and care about the content first. Because that’s what the users care about. Assume the users’ interests are more important than your own.
- Quit acting like CSS is some giant-ass mistake that needs fixing. A group of people who were collectively smarter than us wrote those specs. They didn’t make mistakes 7 . Assume you are making the mistake, not them.
- Server-side rendering was not invented with JavaScript and it doesn’t have to be implemented with JavaScript. There are many ways to render content on a server. Assume non-JavaScript solutions existed first.
- JavaScript either is neither the God-send nor the hell-spawn for your project. It is a tool which you can choose to use incorrectly. Learn when JavaScript is the right tool for the job.
- Quit doing hard things for simple problems. Quit doing things that are degrees of difficulty harder than the problem. When a problem presents itself, look for multiple solutions, and then choose the simplest one. Assume the simplest solution is the best one.
- Quit chasing the new and shiny in your day job. I, too, am excited about the new and shiny. But I put a 2-year buffer between me and prod because I don’t want to be the person to have to discover browser bugs, framework bugs, or even compiler bugs.
Or whatever. Don’t do this and continue to be an Alphasshole, Betasshole, or an otherwise generally contemptuous person. I don’t care. At least I can sleep better knowing that you know that I know that you now know that you’re an asshole.
Happy coding!
Footnotes, Sources, and Whatnots
1 Express.js was released in 2010.
2 PHP started development in 1993 and was released in 1995 which means that when express.js dropped, PHP was driving to the store and buying clove cigarettes.
3 When I say it’s mutated, I mean that nesting jumped from Sass to native CSS. And CSS does it differently. So now Sass has to change how it does nesting because of how CSS does it. It’s bad. It will introduce lots of things you don’t want to happen. I’ve written A very long explanation of the future problems we will have with nesting and why it’s problematic.
4 People have been talking about how left-pad broke the internet and some wise folks have called out that it was pretty silly that such a simple function got to be so ubiquitous that it had the power to “crash the web”. But what’s also dangerous is the person actively trying to become ubiquitous. Every PR that involves adding a new dev dependency to any project should require the developer to hand-write the entire dependency tree. That would probably save a lot of future heartache.
5 I do not, in fact, have strong evidence that the Good Lord intended for WebPack to be told to, “fuck off good and proper like.” However if the Good Lord had something to say about cotton blends, He’d probably also have something to say about using a JavaScript build utility for building styles.
6 Yes, you can have strongly-typed CSS, but it’s insanely tedious because those “types” are not like any types you’d expect from any other language, and the syntax is going to be a huge pain. Also, you have the option to set it to not inherit which is, in fact, the most unCSSy thing ever. So please. Don’t.
7I don’t mean CSS is perfect and flawless and should never be questioned. I would definitely say that the implementation of em was weird. Their choices for naming was a bit odd; you could argue many font- properties should’ve been text-.
I don’t think Layers was a mistake; I think they meant to do what they did. But I think they should not have done it because Layers is supposed to be an attempt to explicitly control cascade, but it’s only ever going to be useful so long as you maintain 100% control over every style on your site and are adding every style to a layer. If you don’t, the non-layered style will over-write the layered one. I get why that’s the case because that makes it a progressive module and allows interoperability with the vast majority of sites which don’t use Layers. But that also means that Layers is going to be pointless in any system where styles can be generated / imported from multiple places. Which tends to be a lot of CMS and even some plugin-rich SPAs.
Same with CSS Nesting. I think they knew what they were doing. But CSS Native Nesting is not string concatenation / interpolation that Sass did. CSS Native nesting uses the same mechanism as the :is() selector. That’s incredibly problematic because that selector will always apply the argument with the highest specificity to all of the arguments.
So look at this:
#article-container, .article {
h2 {
color: red;
}
}
In Sass, you’d get #article-container h2, .article h2{} which is perfectly reasonable and intuitive. But over in CSS you’ve got :is(#article-container, .article) h2, which means in practice you will now need a specificity greater than [1,0,1] to override .article h2 which you thought would have a specificity of [0,1,1]
Permalink
From one Frank to another, I love this… well, save for the CSS part, because I continue to think CSS has become a fat, bloated, pig of a thing and is disgustingly complex in real-world usage and is doing WAY too much beyond its original intent… but, that aside… yeah, couldn’t agree with the rest more.
Permalink
I actually also kind of agree with that assertion.
CSS Layers and CSS nesting I think were unnecessary features that only served developers and had no interest in helping end-users.
Animations and transitions I’m not mad at, but I almost wish there were a fourth language that could’ve handled that. CSS’ syntax is too simple and JavaScript’s is too complex.
I love how SVG exists and is this fantastic approach to rendering even complex imagery online and I think that was a wonderful route to go. If we had some sort of dedicated language for declaratively (ish) writing animations and transitions, that would go a long way in filling in that gap.
Permalink
Exactly why I’m writing my own website with just HTML, CSS, vanilla JS, and Jquery. SQLite for database because unless your queries are in the hundreds of thousands per second, it usually has better performance than other relational databases. The needs of multinational tech companies are different than the needs of most companies and the solutions provided by JS frameworks have very specific use cases (interactive, data-driven content to use your words) that aren’t widely applicable to every single website.
Permalink
my own personal site frankmtaylor.com is very basic. I used assemble for some very mild handlebarsy work that amounted to simply putting header, footer, and nav on every page. Honestly, I think that’s what most of us need for our very basic sites: a way to share common units of code across multiple pages. The only reason I chose a handlebarsy / assemble approach rather than PHP was because I didn’t want to have to spin up MAMP locally. This was the path of least resistence.
But the styles are written in generic CSS (And using layers, because I use my personal sites for experimentation). JS is barely needed, so, it’s not … fancy, either.
Could I add a CMS to it? I mean, I probably should. But… for how often I actually update it, I wouldn’t save hours by setting up an implementing a CMS. It’s faster to just edit the content in git, push up, merge to main, and let Github’s machinations deploy. Simplicity is a saner path.
Permalink
Hello, I’m a new web developer, but I think jQuery is a good when building small app, and use framework for complex and large app ,,, is jQuery without npm can managing and centralizing application state???? Idk. , but I like using framework like angular v18,,, features , that jQuery no have it…
Permalink
look jQuery is good for lots of basic -> intermediate interactions.
If you’re at a point where you’re actually thinking about state, jQuery is not the right tool. If you’re developing a highly interactive application of the degree that you actually need to maintain information in state, you need more than jQuery. That’s when it’s time to decide if React, Vue, or Angular is the right choice.
TL;DR : jQuery is not for state.
Permalink
Sorry to say this, but your website sucks :(
I tried to read your article on my phone last night and gave up after the scroll kept jumping and loosing track. Sent it to my computer, hoping it would be better… Another proof that hope is not a strategy… Anyway I was somehow able to read your article and got to the comments… Oh boy :( I HOPE sending this comment works
Permalink
Don’t apologize for saying that.
Can you share details for why it sucks? Any specifics you can give would be great.
Permalink
Can you explain why CSS should help end users? End users don’t give a fuck about CSS. I’ve been writing CSS professionally for over 25 years and have never considered that.
Permalink
The purpose of CSS is to make content presentable to end users.
Most end users neither know nor care about CSS. However part of the original design of the cascade is that there were three cascades: a browser cascade, author cascade, and end user cascade.
!importantwas created as an accessibility tool so that the previous cascade could override the next (i.e. author could trump end-user).CSS helps end users with regard to accessibility. Users with dyslexia, visual impairment, or some other disability have the third cascade for overriding our (the developers’) styles. This exists in every browser as the ability to scale/ zoom, set default fonts, etc.
CSS also helps end users as its the means by which we make web content printable (or, actually, faxable; that’s where the media query got its start, as a means to make a web page suitable for fax).
End Users definitely don’t give a shit about CSS directly, but they give a Johnny-on-the-Spot’s mountain of shits about being able to consume content. And CSS is the means by which content is consumable.
And if you’ve been writing CSS professionally for over 25 years and have never considered the relationship CSS has to content, SURPRISE!
Permalink
Once upon a time, there were no ends. You were a web developer or, before that, a webmaster. Then the fracture came and if you said that you worked on front end code you were immediately dismissed as someone who only made things look pretty–that wasn’t REAL engineering. Worse still, if you were a woman working in tech everyone assumed that all you could POSSIBLY do was make things look pretty so every time you were introduced to someone new on the team they would say something to the effect of “Oh you must work on the front end!”
One day, all the raging Millennial egos decided they’d get back at the nasty people who’d hurt their feelings by making front end development so ridiculously convoluted that even they couldn’t really understand it anymore. This was, in many ways, an awful and tiresome repetition of all the idiotic mistakes that had already been made a decade ago by people with actual experience maintaining large code bases for far longer than any of the Adderall addicts will ever hold a thought let alone a job in their lives but there was enough of a steady procession of new tools all trying to outdo one another that nobody sat around huffing their own farts for too long so there was still some progress happening every once in a while even if it was entirely accidental.
Then Facebook released React. Every bootcamp taught React exclusively because everybody wanted to work at Facebook. If you asked a question like “do we really need to curate two complete copies of a tree of totally arbitrary complexity and exhaustively diff them every single time any piece of data changes just to change a string in a checkout button?” you were obviously a heretic who couldn’t possibly understand how wonderful Facebook was. Once you got on board and learned to accept Facebook’s infallibility, if you didn’t immediately understand how a function named “useEffect” that performs 20 completely different tasks depending upon the magic parameters it was passed is SO much easier to understand than a small handful of clearly-named component lifecycle methods then you obviously were not qualified to change the color of a button as well as a 22 year old CTO who definitely deserved his title could.
In fact, the only way that any of this could possibly be better is if we plastered a layer of fake-ass typing on top of a language that absolutely does not want it and made it so that everyone suddenly had to rely on some weird sourcemap thing that almost never worked to debug anything. Then we can finally start deploying something with a truly modern serverless architecture like Amplify which makes it fundamentally impossible to run let alone debug any backend code ever. Type checking prevents every kind of bug ever so this is totally cool and good.
Hey, let’s update React to the latest version so we can use this shiny new feature that might actually make some of our awful code slightly easier to read. Ooops, updating all the Typescript bindings everywhere will take six people six weeks of work. Oh well, time to go work somewhere else. Facebook’s for boomers anyway.
Permalink
I didn’t go after TypeScript because I wrote this before I went on vacation and a few days in the woods completely erased the trauma it caused.
If I did write a rant on TS, I think I’d have to hit publish and then go to the woods for a solid week.
Permalink
Oh man, I’ve spent so much time ranting about TS I can’t even remember what I’ve said anymore. That said, my rant boils down to something like “learn proper fuckin JavaScript and you don’t need fuckin TypeScript.”
Permalink
love this comment
Permalink
Now expand this to cover all of computing from embedded on up and you’re about half-way to figuring out why software is almost universally, at every level, utter and complete shit.
Permalink
If most of the general public knew how awful software is, most of us would be executed.
Permalink
I was promised swearing you could easily have used more swearing in fact I’m sure there’s a npm package that can simply inject more. Wonderful rant though I agree with so much you have said
Permalink
Believe it or not I was almost tempted to write an NPM package for giving the option to hide/remove the swear words for folks who might take offense, and then I re-read all of the words I wrote and say, “nah. fuck that.”
Permalink
This was a great read, thanks for putting it together. I hate when developers forget their job is to make the complex simple and not the other way around.
Permalink
YES
Permalink
This is all on point and I wonder if you have looked at the buzz around HTMX because the idea is to go back to HTML and hypermedia principles and making it easy to just get server rendered snippets without this bulky nonsense – https://htmx.org/ – like there is a real theoretical basis to what you are talking about w hypermedia. it’s not just finding frameworks gross as they are. https://hypermedia.systems/
Permalink
I have looked at HTMX. I haven’t found a reason to use it professionally but I think it has great potential for solving some problems in a simple way. I’m looking for an excuse to use it on a side project. I think HTMX potentially is in that “jQuery” territory of simplicity + utility.
Permalink
Simplicity has always been my primary drive, yet I shake my head (a lot lately) every time I look at the clusterfuck that the web (and the industry) is turning into by many of these new whipper snipper developers.
You wrote the feelings I couldn’t easily compile into words, and there’s a lot more that could be expressed about the back-end dev as well.
And do we even want to get started on all the new programming languages. Almost every month some dipstick thinks they can re-invent hot water by writing a “cool new” programming language (or framework for that matter) that “5 of their friends are using right now, and you should too, IN THE ENTERPRISE ENV.”
But let me mention my special beef with Rust, not because it’s trying to replace C (it simply can’t…BAD programmers write bad code, C is not to blame) but because every fucking piece of software today has to be (re)written in Rust. Not because it solves a specific new problem (it has not found a problem to solve yet IMHO), but because it’s Rust…so “mandatory.”
Hopefully all of this crashes and burns soon, so we can go back to simplicity once again, because there’s no other way.
Permalink
I tried out Rust for about 30 minutes and found myself too aggravated to keep going. It felt like TypeScript with narcissistic personality disorder.
I won’t deny the memory-safeness of Rust. But good grief was my experience not worthy the hype. But also, my experience is primarily front-end with a decent amount of C# and a dab of Java. So Rust was not my jam.
Permalink
Wow.Someone has gone public with some of the thoughts I’ve been thinking in private for 5 years.
JavaScript frameworks? Whose bright idea was that? Let’s build some bloated edifice whose real job is to force you to learn how to reinvent the wheel in a rococo bureaucratic manner, because standard JavaScript isn’t trendy, or too much like hard work for people who didn’t learn real computing before aspiring to be the software development version of an “influencer”.
As for CSS, I understand the motivation – let’s put all the styling in one place so we can keep the website appearance consistent across multiple pages with a single point of reference. Good idea. As for the implementation of some of its features, I’m not so sure.
I still find keeping element sizes defined relative to the viewport to be a chore, even after all the bloat additions, not least because there are still some browsers that don’t support this concept properly. As a corollary, I still have to engage in at least some JavaScript to ensure element sizes are tidy even on relatively simple pages.
Oh, and whose bright idea was it to introduce scrollbars that are so tiny, you need to be a tenth dan black belt mouse operator to grab them? Forget using some of these on a touch screen, that’s as futile as trying to push half a kilo of sunflower spread up a squirrel’s rectal passage with a red hot knitting needle.
There’s one of those tiny scrollbars on the right of the textarea I’m typing this comment in. Can I scroll using it on a tablet? No. It’s all of 2 pixels wide.
Meanwhile, the pathetic framework fetish is now infecting other domains such as PHP. I tried looking through the docs for Laravel, and ended up asking myself just WHAT is the point of this?
Yes, I have something of a love-hate relationship with JavaScript, because it enables you to solve some problems with brilliant finesse (symbol tables for a cross assembler being a classic example) while making certain other tasks a painful chore (event handlers that take custom arguments – solving that one was fun I can tell you).
But adding megabytes of framework bloat isn’t going to improve matters. Can’t see the point of Angular, React or Vue. Or, for the time being, any of the other framework plankton that have been multiplying like a software Cambrian explosion gone horribly wrong.
Permalink
As a software engineer, who used to be a physical “real” engineer, I firmly believe that this software stuff is here to do a job and do that job as simply and easily as possible.
I’ve been ranting against all these js frameworks for years, and I prefer to go back to jQuery because it does what I tell it to. These other frameworks try to tell me how to write the application.
Permalink
Just a heads up, there are issues with this site when viewing it in mobile.
It appears that the vertical margins are included in the overall width, which means you have to scroll horizontally to view the full width of the site.
It’s making it difficult to read the content.
Permalink
Thanks for giving me some details on the issue. Should be resolved now!
Permalink
I’ve been web-coding since the first Clinton administration. And coding generally a decade and a half before that. (Hey, I started young. But yes, I’m old. In programming terms, I’m paleolithic.)
I find this rant reassuring because I think a lot of these same things and just go into Principal Skinner mode. (“No, it is the children who are wrong.”)
I learned Rails over ten years ago, and discovered the “bible” on learning rails required fifteen (15!) different technologies before you could get started on Ruby and Rails. And each technology was presented as both “easy” (often “just like English!”) and mandatory (“you can’t possibly learn Rails without also learning Cucumber and this test suite, but it’s so easy it’s no problem…”).
Of course, the book was several months old, and the versions had to be exactly the same, because everything had changed in those few months, and some of the mandatory things in the book had been superseded by NEW mandatory things.
And I just got through with a place that used Angular (which is awful) and was trying to move to Vue.js (which is theoretically less awful, but darned if we weren’t having the exact sample problems), and now I’m all…”Well, Svelte…or maybe just nothing. Nothing sounds good.”
Anyway. *shakes fist at cloud*
Permalink
When all you have is a hammer, everything looks like a nail.
We don’t need to solve everything with one tool.
Permalink
I’d love to read your thoughts on TypeScript.
Permalink
If I wanted feedback on everything I’m doing wrong with zero contributions in how to do it right I’d rather have lunch with my mother.
Permalink
PureScript. It’s not perfect and it is forcing me to learn how to program for reals this time, but it’s so much better than TypeScript.
What is it with mothers?
Permalink
Hahaha, that’s hilarious! Literally laughed out loud. The comments section of this article is true gravy.
Permalink
As a Front-end Developer, I enjoyed this rant very much! I think one problem with overusing frameworks is that new developers, who have just learned how to use HTML and CSS, dive into frameworks like React and Angular immediately without ever encountering the problems those frameworks are supposed to solve. Therefore, a lot of reasoning about what technology suits a project goes out the window from the start. I had that exact problem and had to relearn a lot of basics just to make those decisions a bit more accurately.
Permalink
THANK YOU!!!
What a beautiful rant.
I am in agreement 100% on all points and have had a very similar experience in my career. Finally someone has written a worthwhile piece on these topics.
Permalink
This is hilarious. I’m a therapist. To be clear, it was a late departure from a tech background. I absolutely loved this! I was dusting off my HTML/CSS/JS skills for commercial front end stuff when I came across this. What a great synopsis of the contemporary evolution in this world. You answered so many questions in this new alphabet soup universe of coding for me!
Permalink
Go Back to Therapy. leave this place.
You would make a killing from front-end devs who don’t have to give a tech lesson when they share how they’re mad that Todd from the design system team wants to implement immutable web components as microservices.
Permalink
I knew there was a reason I prefer working on back end development so much more than front end, and you just said why. Back end is focused on solving problems and delivering reliable code. Front end is focused on a never ending barrage of frameworks & packages all built around trying to use Javascript for everything and also trying to unshittify Javascript to make building everything in it even remotely feasible. And performance is an absolute dogs breakfast.
If I was just getting into this industry today, I think I’d get into plumbing or farming instead because dear god have we strayed a long way from delivering effecient, simple solutions.
Permalink
Earlier this week I had a bug. I knew the likely cause, and I wrote some unit tests, where I successfully identified the cause and got a resolution.
Except Jest didn’t want to play with rollup (namely rollup-jest, because that’s abandonware now). I didn’t want/ need to add Babel to the mix, so I tossed out Jest entirely and used @web/test-runner, and added Chai.
I had to do that because my environment would fail to build (which was a Docksal setup running in Colima for a Drupal setup). Even though my test dependencies were marked as dev dependencies. Wouldn’t. Build.
A few weeks ago I opened an issue on a rollup plugin because If the word “global” appeared anywhere in a comment in the entry file, the optional chain operator
foo?.barwould throw an error.This is my world.
It’s madness. Why are we choosing this for ourselves?
Permalink
I was actually in the process of writing an article like this as my second blog post ever. But you took a much more far reaching detailed approach. I also like seeing your anger come across on the page, because that’s how I feel as well, but I’m scared to express.
My article was going to focus on how useless Docker and Kubernetes is if you actually build a company correctly from the start, and how JSX is not just a matter of opinion but an objectively bad invention.
React brought three ideas to the forefront.
Web based components architecture
A decent way to manage state on the frontend.
JSX
One and Two are fine. JSX is horrible, but for some reason we kept it. I could see why someone would come up with it for a prototype for the idea. But it is literally just bastardizing HTML, a working markup language for thirty years, the base of the entire web, the most popular language of all time if you consider it a language. I hear “oh well it’s better for people who prefer JS”. What? Who knows JavaScript, an optional web language originally just designed as a little sugar on your HTML and CSS, widely known to be a mess albeit now powerful, but doesn’t know basic HTML. And the syntax of JSX is by no means obvious to anyone who picks it up. It must be compiled, you can’t just add it to your website, you generally build the whole damn website in this useless language, when all you needed was a for loop and if statement as an attribute on your clean JavaScript. It’s literally nuts.
And Docker/Kubernetes, how about you just build your company with one or two languages, a monorepo, everyone uses the same operating system, and you scale the damn thing with a PaaS if you need to. Problem solved, every project can run locally or on the PaaS… but no, we need to give people useless jobs or something.
Am I crazy? I really feel crazy. I watch these YouTube videos now where these really smart people explain the complexities of every web tool and web company trying to piece them altogether like a mad scientist. How much more useful they would have been building their own solutions on a normal compiled statically typed language serving static HTML in dynamic ways while controlling their own servers and knowing unix. And I say that as a pleb web developer.
Can people even build SQL databases anymore?
AHHHH!!!!
Permalink
I tried to edit your comment and wrap your three items in an ordered list but apparently something in wordpress is stripping those out so sorry about that.
I absolutely agree that JSX was not intuitive. The first thing you learn about JSX is, “this is JavaScript, not markup” and that seems…. problematic. It’s got major, “the cyber truck can temporarily operate as a boat,” vibes. Which is to say, “anything is a fucking boat until it sinks.”
As for Docker/K8s … … I mean… don’t … even get me going.
I am regularly amazed at the number of things I have to know to do my job that aren’t actually my job, like how to use docker containers, and then container managers like Docksal, Colima, DDev.
and man … SQL. I’ve talked about that before.
Go ahead and write your rant. Rants are for your own mental well-being, not anyone else’s. But feel free to come back and share a link.
Permalink
First of all i love this blog post. Im a product designer / uxer so i love that you thought about the content… Great job.
Someone said you site sucks – they suck. Having said that if you ever need a wireframe hmu :)
Permalink
In your comments on content and the list of what you can’t do, you could just summarise this by saying without content you have NOTHIIIIIING. Not a thing.
Design is secondary to content. Tech is secondary to content (mostly). You could put a plain text document up (yeah ok there’s tech there) and you have an actual thing people can benefit from. Put up a cutting edge website with zero content and what do you have? Nothing. Pointless.
Permalink
Spot on. Yes, I “yell at the cloud” also, but experience does matter, no matter what “modern bro-grammers” think. Take your NTFs and shove it.
Permalink
You could take this entire essay and find every instance of front-end/React/JavaScript and replace it with back-end/microservices/containers and it would still be 100% accurate. Sadly.
Permalink
I have an arbitrary maximum reading time I’ll do for posts and it’s about 15 minutes. Otherwise, yes, I would’ve gone hard on how fucking annoying it is that I have to have Docker, Docksal, Colima, and sometimes even DDev and I can spend half a day elbow-deep in YAML files and shell scripts when All I’m trying to do is move the fucking button 20px to the right.
Permalink
Three thoughts from me: great post, how I work now, what I apply all of the above on.
Such a great post. I agree with almost everything except for part of the CSS nesting bit. While for single-liners nesting indeed makes it uglier and bigger, in a lot of cases I still use it becase it somehow feels logical like that.
Finding the selectors, after looking in the inspector, that gives me a headache just by looking at it. I find that soooo annoying.
On simplicty: I had found Go and its standard library some years ago and I think now it reached the level of feature richness that I need and happy with. Started putting together some sort of a open source server that is highly opiniated, but also simple. Repo is here https://github.com/edimoldovan/gowire — intention is to have something like hotwire but way simpler. Not that it would be needed for anything SSR with Go, but I need for an application/product I’m building.
Since I mentioned what I am building a little, I have started something that would like to incorporate all the points, done well, of your post, well before I found your post. It’s https://handover.zip — with name hinting towards filenames which I received from designers long ago.
Permalink
I’m currently writing an article that explain all the problems that CSS Nesting can and will cause. I know it feels logical. That feeling is a lie.
Permalink
I subscribed to your feed so I will be reading that as well. Looking forward to that.
Permalink
Give this man his flowers!
Permalink
I created my first website in college in 1994 and have been doing it professionally since. I have always maintained a “right tool for the job” mindset, and never “I used this tool last time, so I might as well use it again this time” unless “this time” is a clone of “last time.” Generally speaking, I loath frameworks, I hated LESS then I hated SASS even more. I have a love-hate relationship with CSS and miss the skinny cuteness it once had, but I figure just because it can do something doesn’t mean I have to use it for that.
I loved PrototypeJS before I dumped it for jQuery then ES5 made me start questioning my love (and kind of start phasing it out). ES6 turned me into a JS Vegan, all-natural vanilla for me and no looking back. I don’t care that I have to write a few more lines of code, since technically those lines would still be there if I used jQuery anyway, along with a fuckton of shit I don’t need. Besides, writing vanilla JS makes you better at writing JS. I think the jQuery-monkeys are in large part responsible for the abomination that is TypeScript.
When I hire anyone that will be coding JS, a standard screening question I give the recruiter to ask is: “What’s the difference between jQuery and JavaScript” and I tell them if the person gives any answer that doesn’t include something like “jQuery is JavaScript” they should pass on that person and move on. Hard stop. I don’t even want to talk to them. It’s really amazing how many so-called frontend coders out there don’t think of it like that.
Anyway, my jQuery-hate notwithstanding, I loved this article. Coming from a major multinational tech company that can’t seem to decide if it wants a centralized or distributed development model (and changes it ever few years), the sort of problems you’re ranting at really hit close to home!
Permalink
Permalink
Hey, great rant and a great read
I really enjoyed it.
Just wanted to let you know that your site is not very readable to me because the font size is really small, and when i zoom (enhance the browser to 125% or whatever) the page just make a zoom like I would if I would pinch an image, then the text overflow the screen so I need to pinch zoom out and the text is still small.
So I read it on reader mode but that don’t have any code highlighting and other nice things
I’m using safari on iPhone
Permalink
thanks for sharing.
I’ve actually just put out a small update to the blog to improve the print experience. It doesn’t look fantastic in your reader mode, but I want you to know that’s on my radar. thanks for letting me know.
Permalink
we reached the peak when wordpress – a CMS developed in php – adopted React – a framework that does not support php.
I love you.
Permalink