TechTakes

1401 readers

202 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]

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.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 8 points 4 months ago* (last edited 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 has 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

[–] [email protected] 9 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] 7 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] 2 points 4 months ago* (last edited 4 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] 2 points 4 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] 1 points 4 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] 3 points 4 months ago* (last edited 4 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.