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.

  • deborah@awful.systemsEnglish
    1·
    5 months ago

    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.

    • David Gerard@awful.systemsMEnglish
      0·
      5 months ago

      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.

      • self@awful.systemsEnglish
        0·
        5 months ago

        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

        • Steve@awful.systemsOPEnglish
          0·
          5 months ago

          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

        • shastaxc@lemm.eeEnglish
          0·
          5 months ago

          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.

          • froztbyte@awful.systemsEnglish
            0·
            5 months ago

            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

            • Steve@awful.systemsOPEnglish
              0·
              5 months ago

              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

              • Steve@awful.systemsOPEnglish
                0·
                5 months ago

                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.

                • paceaux@awful.systemsEnglish
                  2·
                  4 months ago

                  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.
                  • Steve@awful.systemsOPEnglish
                    2·
                    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.

                  • V0ldek@awful.systemsEnglish
                    1·
                    4 months ago

                    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

          • manicdave@feddit.ukEnglish
            0·
            5 months ago

            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.

            • self@awful.systemsEnglish
              1·
              5 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)