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 expressedRead More

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.

  • self@awful.systemsEnglish
    1·
    6 months ago

    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)