this post was submitted on 29 Jun 2024
1 points (100.0% liked)

TechTakes

1371 readers
24 users here now

Big brain tech dude got yet another clueless take over at HackerNews etc? Here's the place to vent. Orange site, VC foolishness, all welcome.

This is not debate club. Unless it’s amusing debate.

For actually-good tech, you want our NotAwfulTech community

founded 1 year ago
MODERATORS
[email protected]
1
A Rant about Front-end Development (blog.frankmtaylor.com)
submitted 4 months ago* (last edited 4 months ago) by [email protected] to c/[email protected]
47 comments fedilink hide all child comments
 

A masterful rant about the shit state of the web from a front-end dev perspective

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 2010. 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.

top 47 comments
sorted by: hot top controversial new old
[–] [email protected] 0 points 4 months ago* (last edited 4 months ago) (1 children)

I signed up to this instance because I feel this in my bones.

I cut my teeth on PHP CGI in the late 00's before shifting to python CGI because my university had banned PHP on the webservers.

Frontend wasn't exactly a term back then. I'd picked up a bit of jquery into my server generated Django templates, I was playing with template fragments in 2011 and life was good.

I mostly avoided the SPA fad, but a (short) stint at Wayfair had me end up writing react and dear God the amount of indirection and tomfoolery involved with effectively writing the app a second time left a sour taste in my mouth.

These days I mostly write embedded daemons in rust for Linux devices. I wrote a munin replacement in rust because packaging perl for Yocto is a struggle. I needed to serve a website, so I found a jinja style library, setup my templates and fragments and dropped htmx into the frontend.

Life is good again.

I have friends/coworkers who argue with me that I should write SPAs but they don't get that I mostly want to avoid fighting frontend tooling and get shit done. A backend serving templates is miles more ergo than react and I don't have to deal with the NPM upgrade treadmill. I don't get daily dependabot alerts.

Don't get me started on golang, meteorjs, and lambdas

[–] [email protected] 0 points 4 months ago

welcome!

there’s something weirdly cozy about systems development, especially coming from modern web stack work. it might be that there’s no sandbox so you can do what you want, the toolchains are usually a lot lighter, and the APIs usually aren’t designed by the least honest people you know (my rant on the fuckery surrounding the Web Components spec is still incoming)

lately I’ve been working on the rewrite for our instance’s archives, and I’ve been getting very good results from a custom static templating engine and unpoly as a progressive enhancement library. after years of dealing with react’s bullshit, it’s surprising how much functionality you can get out of carefully structured markup and CSS, with a tiny amount of strictly optional JavaScript that mostly enables partial repaints (maybe the only good bit of SPAs? I still need to benchmark it to see if that’s even faster than native rendering) and a controlled, predictable amount of markup enhancement that seems to stay the fuck out of the browser’s way

so far it’s definitely a distinct improvement on what I’ve come to expect from SPAs, which is a world of loading spinners, crawling elements, and jank so severe and universal they’ve taken to naming all its varieties

[–] [email protected] 0 points 4 months ago (1 children)

I'm not versed in the web dev scene, front end or back end. But if you mean the people that design sites where shit isn't loaded in proper sequence and keeps shifting/moving buttons as it keeps loading more shit, then yes, fuck those people.

[–] [email protected] 0 points 4 months ago

so, this isn't so much a design as it is a consequence of how a lot of the technologies involved operate (as in, it's (largely) not a conscious choice for those things to do that shifting (except in the cases of deceptive designs)), but you're fairly correct in that it fucking sucks to have that interaction with sites/systems (because of violates principle of least surprise, etc)

(and probably also sometimes/often falls into that bucket of things where "it works perfectly fine on the dev's 27" laptop with 16 cores and 32gb of RAM and the DC is next door" development applies)

[–] [email protected] 0 points 4 months ago

And the church said? Amen!

Preach it, brudder!

[–] [email protected] 0 points 4 months ago (1 children)

Some people enjoy the front end. Some people enjoy the back end. Some people like accessibility. Some people enjoy the full stack, and some people enjoy gratuitous innuendo.

Not that there's anything wrong with any of that, but just about all software engineering is a dumpster fire today. This isn't the future that was imagined by those resource-constrained titans who came before us, basking in the incandescent glow of the blinkenlights, fearing nothing in this world except dropping a box of several hundred punch cards thus rendering them out of order.

What we really need is a new language, design system, serialization format, package manager, build system, project management methodology, architectural pattern, IDE, and please, please, I'm begging you man, just give me one more framework to tide me over until Monday when the stores open again. My supply chain is under attack brah.

[–] [email protected] 0 points 4 months ago

class SilverBulletFactoryFactory;

[–] [email protected] 0 points 4 months ago (1 children)

This is so cathartic to read.

I have worked with multiple static sites delivered with React, because somebody built an enterprise design system which is so tightly tied into React that it can't be applied any other way.

[–] [email protected] 0 points 4 months ago (2 children)

Lemmy, e.g. this here site, uses React too. Probably about as weirdly as they use Rust, even as the site appears to present an ok front end.

[–] [email protected] 0 points 4 months ago (3 children)

it’d be very nice to have a progressively enhanced static frontend instead since there’s really nothing about any of this that should require JavaScript (and something like unpoly would give us react SPA style functionality strictly as an enhancement on top of plain HTML)

this might be a cool project for someone to pick up once work on Philthy gets going; most of the alternative Lemmy frontends still have an unnecessary JS framework dependency, or are lacking features for essentially no reason

[–] [email protected] 0 points 4 months ago (5 children)

The main reason companies use frontend frameworks is it's easier to continue development through employee turnover. If your app was written in react or angular you just have to hire someone who knows how those work and they can get up to speed pretty quickly. Modularity also allows for code reuse. It increases maintainability. Labor isbtye major cost of software development, so making things easier and faster to develop and maintain is better from a business perspective than ensuring your app can run on a 15 year old iphone.

If you wanna go frameworkless, JS-less, or whatever on your personal projects then fine. If you insist on it in a professional team environment, you're making everyone's lives more difficult.

[–] [email protected] 0 points 4 months ago

Maintainability my ass. Most "reusable" components I inherit on a react project are worse than worthless, they're counterproductive.

[–] [email protected] 0 points 4 months ago (1 children)

I’ve heard this exact same bullshit spun defending choosing golang too, and it’s just as bullshit there as it is here

and that’s not even touching on the aspect of this being based on the extremely toxic “oh yeah just burn them up and find the next one” mentality that his become far more prevalent in the world under the umbrella of zirp-funded bayfuckery gaining international traction

I beg you to go consider whether this is your actual position, or some shit you picked up from someone else. to consider what the effects of this stance are, not just today but in 5/10/15y+. it should be quite easy to see both how it helped us get into the collective pile of shit we now do have, as well as why it won’t ever be good l

[–] [email protected] 0 points 4 months ago (1 children)

Modularity also allows for code reuse. It increases maintainability.

another thing to think about is how this was not invented by frontend frameworks. We did it fine pre-SPAs and pre-preprocessors. It was part of the architecture and strategy. The hard work that allowed us to essentially reskin entire, very complex, projects every couple of years

[–] [email protected] 0 points 4 months ago* (last edited 4 months ago) (1 children)

i'll put myself out there - here's a receipt from 06~07 https://web.archive.org/web/20070512035940cs_/http://www.toyota.com.au/toyota/main/css/elements.css

we were a team of 5 devs including me. We weren't tribed off into separate areas of concern, we all knew the whole project back to front, and (maybe not the most clever move) managed without version control by always being aware which part we were working on. Cos, ya know, communication is easy when you are 5 people sitting in a group.

Don't give me shit about the complexity of the UI in modern apps either. We were dealing with a huge collection of brochure style pages that had plenty of variations. We kept all that css under 500kb. We could achieve the bland flatness of modern uis under 100kb easily. No fucking doubt.

[–] [email protected] 0 points 3 months ago* (last edited 3 months ago) (2 children)

I built sites as large and larger than Toyota with a team of 4-5 devs. Even with some of them being very junior devs, we still managed to keep the CSS under 500kb.

Lots of front-end devs don't understand the difference between complicated and complex.

Complicated means it's difficult to do and hard to understand. Complex means it's got many parts.

All it takes is a little bit of maturity and planning, and most any modern UI could be achieved in under 100kb of CSS. You put on your big kid pants and think about what you're going to write before you write it.

CSS isn't some deep, level-10 arcane magic. You literally gotta roll an occasional persuasion check against a browser.

Thanks for sharing the article, BTW

  • Frank.
[–] [email protected] 0 points 3 months ago (1 children)

I'm a backend developer and jesus fucking christ, 500KB? That's around the weight of code in an actual programming language for a mid-sized project, and front-end needs that much just for CSS? And CSS isn't even that verbose.

The whole Rust compiler is like 10MB and that's a huge codebase, including all the documentation and shit.

One more reason front-end work never clicked with me I guess

[–] [email protected] 0 points 3 months ago* (last edited 3 months ago)

Yeah. That's one of the many reasons I wrote a damned rant about how fed up I am with front-end. It's insane to think web sites telling you about cars or coffee need 1MB+ to do so.

But it happens because front-end tooling makes it so fucking easy to write complicated, bloated code.

Most of my time and energy these days is deleting shit. I delete more than I write. But my proudest achievement was like 7 years ago when I was asked to add a Japanese font.

Took me 6 weeks. I deleted like 15% of the CSS in the process.

Why did it take so long, and why did it require deleting 15% of the code?

Because the dorks on the project used Sass for literally every line. So I had like 400+ instances of someone applying a font-family spread across 80 Sass files. Not a single.fucking.HTML.element received a style. Not. One.

There was no font-family declared anywhere that it could be inherited down.

So over three sprints I had to move the font-declarations into mixins, then onto raw elements, then actually delete the mixins on the classes. Eventually I got it down to like 18 instances of declaring the font family.

and then I wrote another 18 instances where I could apply the Japanese font.

Adding a Japanese font reduced the size of the CSS by 15%.

front-end work doesn't click with most front-end devs, either.

[–] [email protected] 0 points 3 months ago

Thanks, Frank!

You put on your big kid pants and think about what you’re going to write before you write it.

Killer line. THIS is what DESIGN is. The lost art of knowing what you want to do and deliberating over how to do it. The tech industry reversed it and now everyone is figma-ing about like children lost in the forest.

[–] [email protected] 0 points 4 months ago (1 children)

I've been forced to do react for years and I still don't like or understand it. Most times plain JavaScript is easier and quicker to write and quite maintainable if people can resist the urge to take the piss with nested anonymous functions.

I honestly can't get my head around the idea that people can hit the ground running with react, but can't write unabstracted JavaScript. It's like a MotoGP rider not being able to ride a push bike.

[–] [email protected] 0 points 4 months ago (1 children)

I have, in a previous age, unfortunately been the first one to suggest react at work. it’s declarative! the mental model makes sense! it’s kind of like functional programming! why, Facebook is surprisingly good at CS, maybe we should look at graphql too since that seems like such a good fit for react

this venerable house, opulent and imperial, is a festering abomination. as soon as you run into any performance issues or edge cases with react (or far more quickly with graphql, where the edge cases include shit like authentication and API versioning), you’re going to start burning out developers doing the most counterintuitive bullshit ever invented to torture a development team. and react is structured such that performance issues will accumulate in web apps; it’s just a matter of time (and not even that much time) before they do.

that’s why the advice now is to dodge performance issues with server-side rendering, almost like your site should have been fucking static html in the first place, except SSR won’t fire up without a gigantic bundle of JavaScript affixed to it, and in general it’s another source of bugs and weird performance regressions that you now have to debug in two places

and for what? react’s DX is better than HTML and CSS until you hit a wall, then it’s much worse. you can get a fairly react-like set of functionality out of plain HTML with Web Components… except Web Components requires fucking JavaScript for no reason but to not threaten existing frontend frameworks (see our sister community FreeAssembly soon for the gigantic rant and JavaScript library I’m writing about this shitty situation)

[–] [email protected] 0 points 4 months ago

this venerable house, opulent and imperial, is a festering abomination.

Magnificent.

you’re going to start burning out developers doing the most counterintuitive bullshit ever invented to torture a development team.

As depicted in the paintings of Heironymous Bodge.

[–] [email protected] 0 points 4 months ago* (last edited 4 months ago) (1 children)

as a developer my favourite thing about react componentisation is how it makes me and my team more readily replaceable

[–] [email protected] 0 points 4 months ago (1 children)

fuck, this quip’s better than my seeing-red rant

[–] [email protected] 0 points 4 months ago (1 children)

I love when someone argues against something that is arguing against everything they use in their argument

[–] [email protected] 0 points 4 months ago (1 children)

I checked and they do the “well maybe it’s ok in your personal projects” bit a lot, which is very funny because the code for my personal projects usually isn’t garbage

[–] [email protected] 0 points 4 months ago

That's such a weird notion. My personal projects are the cutest, most groomed pieces of code I write, cause I do it out of my own volition. The code at work? Just any shite that passes the review so that I don't have to look at that codebase or think about it lest eldritch worms consume my sanity.

[–] [email protected] 0 points 4 months ago (1 children)

thank fuck neither myself nor this instance have employees, turnover, or shitty little project managers that get heartburn when the stack’s HTML5, CSS, and a non-shitty templating language instead of HTML5, react/angular/svelte/whichever frontend framework the market decided is in demand this quarter, a CSS in JS library, an ORM, webpack, and whichever npm clone tweaks your nipples the most

and you’d better hope you chose “right” on all of those pieces of the stack, cause you’re infantilizing your devs so much you think it’s impossible for them to learn a new frontend framework, or how to do modularity or maintainability in a basic fucking backend templating language. do they also have to ask your permission to take a piss?

but why are you posting here? it’s almost Monday and you’ve got an hour-long, unproductive standup to preside over

[–] [email protected] 0 points 4 months ago (1 children)

praise the circumstances that enable the scourge of b2b saas products imposed on employees at the collaboration factory

[–] [email protected] 0 points 4 months ago (1 children)

if we keep this up, the CEO might positively mention the name of our project briefly during an all-hands, then two weeks later vastly reduce our headcount because the good job we’ve done proves we don’t need to waste money on all these developers

[–] [email protected] 0 points 4 months ago (1 children)

I remember when we used to write our name in our css files because we wanted to, not because our ssh key enforced it for auditability

[–] [email protected] 0 points 4 months ago

I know this sounds like old man shit, but I'll die on this hill. It's a significant fundamental attitude shift

[–] [email protected] 0 points 4 months ago (1 children)

i keep finding so much that's done with JS that there's perfectly good CSS for

it turns out browser rendering is fucking fast in 2024

[–] [email protected] 0 points 4 months ago

fucking exactly! I’ve been doing a lot of CSS-only work for the sneer archive rewrite, and it’s shocking how fast everything renders without JS, and how much functionality you can retain with a good enough CSS framework and careful markup

I’m also working on a JavaScript library and associated rant named fuckery because it turns out you can’t use Web Components without some utterly unnecessary JavaScript, because the W3C decided to do a fuckery

[–] [email protected] 0 points 4 months ago (1 children)

we used to strive for minimum possible front-end payload, and it was an embarrassment to do anything with JS that wasn't backed up by a non-js default. Will never forget how suddenly React removed all those things from front-end team meetings.

They were solid industry-wide concerns that just... disappeared

[–] [email protected] 0 points 4 months ago (2 children)

Remember when our industry cared about loading times?

[–] [email protected] 0 points 4 months ago (1 children)

facebook used to lie about react being faster than native on first load and navigation, in spite of that being impossible by both lived experience and as measured by benchmarks. supposedly templating is just too heavyweight for servers to handle at the mythical Amazon scale literally nobody reaches except Amazon but every shitty manager needs us to be ready for

and now that react can do server-side rendering I guess we’re doing templating again, but in node and much less efficient and with extremely unclear semantics around when it switches to client rendering, and also weird bugs when things render differently under SSR

also it’s still measurably much slower than old school server templating

[–] [email protected] 0 points 4 months ago (1 children)

the mythical Amazon scale

Ah yes, Amazon, the company with literally the shittiest front-end of all in existence. AWS is downright unusable outside of the CLI, but hey, at least they scale??

[–] [email protected] 0 points 4 months ago (1 children)

you know, for as much poison’s been poured into my ear about how everything must be Amazon scale, there’s no way in fuck they use react for their storefront or AWS, is there? I think the only reason react is considered an Amazon-scale frontend (besides Facebook, which also has a shitty UI, though not as bad as Amazon, and notoriously uses PHP for everything) is how hard they push it as part of AWS Amplify, a toolchain they say will help you reach their scale (but from experience: it absolutely will not, it’s just a set of technologies that increase your AWS bill and perform like shit, which is why Amazon doesn’t use it for anything of value themselves)

the only case I can immediately think of of a very major site going from server rendering to react is GitHub (which used to use Ruby on Rails and Erlang, apparently) and it’s been an unmitigated disaster — none of the new features that supposedly require react are good, the performance fucking sucks now, and the thing keeps breaking (I get weird renders with broken styling every few refreshes and apparently I’m not the only one). the fucking thing even hijacks the keyboard shortcuts I use and has become an accessibility nightmare, all in the name of pointlessly turning it into a react SPA and vscode wannabe.

[–] [email protected] 0 points 4 months ago

Hey, GitHub might be shitty in the browser, but did you consider that it's also shitty as an Android app?

[–] [email protected] 0 points 4 months ago

I remember seeing an argument on reddit between a css dev that understood the depth of the responsive design philosophy and a dismissive Reacter that shut them down by calling them an old "list-aparter"

[–] [email protected] 0 points 4 months ago

Mastodon, too, will not give you anything if you have JS disabled.

[–] [email protected] 0 points 4 months ago* (last edited 4 months ago) (1 children)

I'm sorry, but the vast majority of this really just boils down to "all my coworkers suck." Why the fuck are you still there? It sounds like literally nobody you've ever worked with knows how to do web dev

[–] [email protected] 0 points 4 months ago

I'm sorry you are this way

[–] [email protected] 0 points 4 months ago

As someone who’s doing a ton of frontend and backend, and I can’t stress this enough, fuck the asinine attitude that somehow everything that’s even remotely web-adjacent needs to be written or rewritten in pure JS.

Also Node is an abomination and literally every other language I’ve tried is better for the backend. People love to shit on Ruby, but JS has every flaw that Ruby is criticized for and then some, and at least Ruby makes an effort to take some great design paradigms from Lisp.

[–] [email protected] 0 points 4 months ago (1 children)

for the sole purpose of pissing off Java devs everywhere.

ah ah ah! it was written to piss off Visual Basic devs everywhere

[–] [email protected] 0 points 4 months ago

javascript spits in the face of lisp and common sense every time it evaluates, and that’s a lot of spit