Skip Navigation
TechTakes @awful.systems
Steve @awful.systems
• 100%

A Rant about Front-end Development

blog.frankmtaylor.com A Rant about Front-end Development

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

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.

47
47 comments

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

    31

  • for the sole purpose of pissing off Java devs everywhere.

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

    24

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

      16

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

    18

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

      11

      • 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

        10

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

        9

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

    12

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

    7

  • 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

    5

    • 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

      3

  • And the church said? Amen!

    Preach it, brudder!

    4

  • 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

    -6
You've viewed 47 comments.