1. 41
  1.  

  2. 14

    as much as I can appreciate that indeed, the internet has gotten more laden with options, the other thing that changes with time is professionalism, yeah, when you were hacking webpages in highschool, the projects could be done by joining together simple tools, at the time that you were doing that, “professional” devs were slinging around elephantine PHP frameworks that, believe it or not, did exist back then

    1. 9

      I am one of those professionals. My team was using FuseBox, a port of a ColdFusion framework by the same name. I do not miss it.

      1. 3

        ah, ColdFusion, heard it’s still kicking about

    2. 12

      I recall hearing about “framework fatigue” 10 years ago, and no doubt it was already a thing 15 years ago (if perhaps in a different way – these frameworks were developed in order to prevent people from needing to learn the already unnecessarily complex details of dynamic web programming in raw javascript, all the browser-dependent CSS behaviors, etc.)

      It’s trivially true that we can just “choose not to” use frameworks. It’s also practically false, for most professional developers! Because I started off as a backend developer, it’s tolerated when, during my few forays into frontend development, I throw up my hands and say “no frameworks, no jquery – we’re doing this in plain vanilla javascript” – but, just as in my backend work I work with multi-million-line legacy java codebases organized around stupid design trends and relying on insecure and bloated third party libraries that were hyped decades ago & can’t get away with just throwing them out and rewriting them from scratch, my peers who do frontend work full time are stuck in the same situation with frontend trends. (By the time our multi-year migration from GWT to Angular was done, we were expected to move to React, or whatever is hip now. This corporate-mandating hype-chasing prevented the actual frontend people from fixing real bugs and performance problems, which led to shit like backend devs like me swooping in to patch in big ugly blobs of plain javascript.)

      When we are developing for ourselves, we can use whatever tech stack we like. We can adhere to our own aesthetics. (My personal website uses plain static HTML, generated by a shell script, and only one page has any javascript at all.) But for fully a third of our lives, we are required to share tech stacks with our coworkers and obey the dictates of our employers – in other words, we are pushed in particular directions by the junior devs below us (who are prone to framework and platform hype because they haven’t been around long enough to know better, and who outnumber us) and technical management above us (who are prone to framework and platform hype due to distance from the realities of development, and who have power and authority over us). It’s foolish to dismiss those forces – even as we can sometimes, with effort, work against them.

      1. 5

        This corporate-mandating hype-chasing prevented the actual frontend people from fixing real bugs and performance problems

        I bring this up a lot, but I feel like it’s worth pointing out that, often, someone else who’s pushing the rewrite-in-new-thing is doing it precisely because they know that a lot of what should be regular maintenance work is disallowed as not directly contributing to “velocity”, so selling a ground-up rewrite with shiny bells and whistles (which can be translated into “velocity”) is actually easier and then they hope to clean up some of the old codebase’s issues during the port.

        It doesn’t always work, of course, but in some organizations a rewrite in a new language or framework is the only way to get accumulated maintenance done (and even then it’s more just throwing out accumulated cruft and starting over, hoping to avoid the same mistakes as last time and instead make exciting new mistakes this time around).

        1. 2

          By the time our multi-year migration from GWT to Angular was done, we were expected to move to React, or whatever is hip now. This corporate-mandating hype-chasing prevented the actual frontend people from fixing real bugs and performance problems, which led to shit like backend devs like me swooping in to patch in big ugly blobs of plain javascript.

          There’s a real tension here for hireability. At one of my first jobs, I was also working on a massive Java monolithic codebase that served a (sadly famous) website. The framework was custom built atop the Servlet API and relied on abstractions that predated MVC, but used the terms Model-View-Controller in ways subtly but importantly different than the currently widely accepted MVC architecture. It made development for me a nightmare, and every time we onboarded a new junior engineer, we had to reintroduce them to pattern that were basically only relevant to our codebase. Eventually we switched to a more “modern” framework, not because the abstractions were leaky, but simply that it was just too costly to spend months teaching our juniors about these abstractions. Moreover a lot of engineers were fairly angry that they were learning a set of abstractions that were not transferable out of our organization in any way.

          But for fully a third of our lives, we are required to share tech stacks with our coworkers and obey the dictates of our employers – in other words, we are pushed in particular directions by the junior devs below us (who are prone to framework and platform hype because they haven’t been around long enough to know better, and who outnumber us) and technical management above us (who are prone to framework and platform hype due to distance from the realities of development, and who have power and authority over us). It’s foolish to dismiss those forces – even as we can sometimes, with effort, work against them.

          I want to emphasize that different folks have very different aesthetic tastes. I’ve worked with folks who love and swear by dynamic languages, I’ve met folks that want to rewrite everything they touch into monad transformer stacks, and I’ve worked with people all over in between. There’s folks that love classes, there’s folks that only want classes to act as dumb structs, there’s people that like to code in only functions, it all runs the gamut. Working in a team in any endeavor is often an exercise in compromise of opinions with the benefit of having multiple people to assist in execution. There’s no “right” and “wrong” here.

          1. 4

            I want to emphasize that different folks have very different aesthetic tastes. […] There’s no “right” and “wrong” here.

            There are absolutely different tastes.

            On the other hand, there are design practices that are fast and don’t scale (or vice versa), in some objective sense. For instance, I don’t think anybody here would say that whether or not to use revision control is purely an aesthetic matter with no effect on maintainability.

            Very often, novice programmers are attracted to techniques that make rapid iteration easier without developing the associated habits that make the resulting code maintainable, and at the same time, as developers gain experience we tend to develop strong personal preferences based on that experience that begin to outweigh hype and the expressed preferences of our peers. Our experience allows us to reject claims about improved productivity or ease of use that seem sensible to a naive outsider but that (predictably) don’t hold up when executed – because we have seen similar claims and tried them in the past, or because we have a better intuition for the mechanics of software development at scale than the people who invented the new schemes. So, overblown hype specifically targets the top and the bottom.

        2. 8

          Well said. I think at this point I have framework fatigue fatigue. I’ve read so many rants about how react came along and messed up the good old days of vanilla javascript or jquery. And I think many of these arguments can be boiled down to the solipsistic thesis: “Because I have never needed this tool, I can’t imagine why anyone else would. People are making things more complicated than they need to be”.

          React, angular, vue, etc. didn’t make the web more complicated. They were born as a response to businesses pushing new web experiences with different standards of what “good” or “done” look like.

          The value of these tools shows up when testing & QA, collaboration, and maintenance are concerns for projects of a sufficient surface area. Testing a react component is infinitely easier than testing a composite jquery + server-side rendered web UI. Reading framework code is generally easier than reading a jquery or vanilla JS application, because frameworks at their best regulate how ideas get expressed with consistency between projects, whereas each jquery or vanilla js app is organized however the original author saw fit.

          1. 5

            I don’t mind there being so many frameworks; i think of them as experiments that either move towards an ideal way to compose UI (if one exists), or show us something we mustn’t do. It might be more time-efficient to hack on a small project using vanilla JS. When the project is complex a framework might provide abstractions that’ll help with architecting a clear solution.

            What I don’t like though is the ecosystem. People engaging in framework wars, stipulating that everything has to be written with a certain framework, not willing to try something new, … that bugs me

            1. 3

              I wish folks in software engineering (and especially in the front-end space) had a better sense of history, though. Many “new” frameworks repeat the mistakes of older frameworks because they were created by people who are unaware of anything more than five years old. (As Alan Kay says, software has a pop culture but no haute culture.) This demolishes most of the benefits of the rapid experimentation and iteration.

              What I don’t like though is the ecosystem. People engaging in framework wars, stipulating that everything has to be written with a certain framework, not willing to try something new, … that bugs me

              Software engineering leans young, and young people often still haven’t learned that tribalism is a waste of time. If software engineering becomes a proper profession, this will probably go away.

            2. 4

              This is one of the reasons why I’m interested in Gemini. No frameworks, no boilerplate, just write content in relatively simple Gemtext and publish.

              Sure you can do the same thing with basic HTML, but the allure of jazzing it up a bit off CSS or adding a small feature here can quickly snowball and content becomes second to style. Gemini forces you to stick to minimalism and it’s a joy to just focus on writing.

              1. 2

                Just write content without any meaningful formatting. Want to discuss math or physics? Your best bet is inline TeX source (and hope every reader is familiar with TeX). Want to show tabular data? Draw an ASCII table. Want to attach metadata to the content? Yeah, you get the idea.

              2. 1

                Nope, I’m still here. And I genuinely can’t figure out how to start a project; I have to invest too many hours to get any kind of result, only to find that it was probably the wrong one. As to the question of “if you liked the libraries you were using 10-15 years ago, why not just use it?” Well, because all the coolkids went and abandoned them, and they don’t support modern browser features — not that they couldn’t, just that they’re unmaintained. And I’m not so fossilized that I don’t want to do new things. I just believe in the guiding philosophy of “easy things should be easy, and hard things should be possible”, and that what’s out there right now fails utterly. You have toys that don’t support any hard (interesting) things, and you have frameworks that require a religious conversion, and nothing in between.