5 ms·

The frontend answer to complexity had to do with young/new devs fomo’ing into resume driven development and augmenting their growing identity/ego as a developer

The frontend answer to complexity had to do with young/new devs fomo’ing into resume driven development and augmenting their growing identity/ego as a developer. But this Java shit, that has to all come from enterprise solutions right? I can’t imagine there were tons of influencer-like blog posts that JavaScript had. What hell hole did those Java ideas even come from? Blah. One way or another, people manage to fuck everything up. We just can’t have nice things.

yamtaddle 4y ago
I think some of this is because it's way harder to write a new library for a well-established language & ecosystem and become well-known for it, than it is to do the same in a new ecosystem. This goes for languages and frameworks both—React, for example, generated tons of opportunities like this, to become known for something by basically solving a problem that'd already been solved 1,000 times—but with React. Like, if you want to build your résumé and get offered some of the cushier programming-adjacent gigs and get to present at prominent conferences and generally become A Name, how likely is that to happen if you try to launch some big web framework, or an auth library, or an ORM—in Ruby? Or Java? Nah, too crowded. But if you pick some up-and-coming language (that's up and coming in part because everyone involved is doing exactly what you're trying to do) or hook your wagon to some new framework's (or database's, et c.) hype cycle, well, now you're talking. As a bonus, many of these projects require little or no novelty—it's all well-trod territory. Just half-competently do what hundreds of others have already done, succeed at promoting it (tellingly, this is the harder part) and you're a rockstar. And hell, maybe doing all that does demonstrate some kind of remarkable and valuable skill, for all I know! But the point is, if that's the kind of thing you're trying to do, you need churn, and a bunch of people all trying to accomplish the above drives that very churn. Very little of that activity actually advances the industry, and the churn itself is a huge drag on everything.
r_transpose_p 4y ago
15-25 years ago, there were hip-for-the-time tech influencer bloggers who would write all sorts of stuff about whatever new frameworks and tech were available in the Java world. If you take all the scary Java Enterprise buzzwords in one of the previous posts on this thread, and look them up, you'll find that they all came about, roughly, between 1999 and 2007. I don't fully remember what all the hip influencer tech blogs were during that era (I recall "Joel on Software" having been important), but I do remember that people who paid more attention to such things were really into "Enterprise Java Beans" at the time. So the JVM world might suffer from a bit of an analogous problem. But that world's complexity explosion was decades ago. My feeling is that backend has always been complex, depending on the scale you were trying to operate at (and how much scale your framework and ecosystem forced you to think about whether you wanted to or not). The best you can do to mitigate it is continually ask "Do I really need my backend to handle the scale I'm designing it for?" and "Is all of the complexity in my preferred stack still necessary, or can some of it be hidden/automated?"
- jesuscript 4y ago
  Heh. So propaganda (or marketing as we now know it) has always worked. When are we ever going to get hip to that reality?
  - r_transpose_p 4y ago
    I try to remember that this decades cool hip software trends might become the next decade's enterprise Java. And that's the outcome for the successful stuff! (Doesn't mean you shouldn't get into it though -- if I'd jumped on enterprise java 20 years ago, I'd probably be richer than I ended up by just working on the software I was interested in)
rektide 4y ago
The response I dont see represented is that we were more ambitious in the past. There were all kinds of negative effects, bad tools & out-of-touch architecting that was begot; we can acknowledge that, certainly. But that almost all representation of Java here so emphatically emphasize only the negatively bias, without recongizing also some of the idealism, hope, & progress is to our loss. We were also trying really cool things with many of these java efforts. Rather than a main() routine that imperatively did everything, there were future-sightes notions that we could have a bunch of ambient systems available & interconnected. OSGI solved some thorny library versioning problems, and as a bonus allowed for a very strongly manageable runtime for modules. EJB brought objects up to a higher level, a greater management tier with more interoperability of objects across instances. We were interested in trying more, in tackling harder problems, that microservice era has masked over, deliberately chosen to ignore. Over time we got more refined forms of many of these systems. Maven calmed much of the ad-hoc madness of Ant. CDI was a more reasonable EJB with event more competent management. JSP kept getting better component libs. OSGi actually was... decent all along, sometimes legit useful. But the idea that Java was absurdly troubled seems to endure & be enormously popular hatred/FUD to spread. The fads of today are exactly the opposite of the better managed more flexible runtime trend, where the JVM keeps rising as a more capable, flexible, malleable, adaptable, controllable way to tackle processes than the processes at an OS level. And certainly, there's a lot of ease we've bought ourselves by doing much much less. Statically compiled binaries are an example of yet another means of doing less, of finding easy routes; powerful simplifications that have greatly eased many folk's lives. Less is great, sure. Isolated container instances with dedicated apps is pretty easy to deal with. But there are still constant undercurrents, pushing us towards more interesting complected runtime arraingements, where virtual machines (not fully virtualized os'es but systems like glassfish or erlang, where many sub-processes are co-resident) come back. The idea of very quick very easy to spawn sub-processes allows for interesting security & modularity, where-as today services are almost all monolithic app servers that have complicated multi-user authentication & authorization concerns. We could make simpler safer software if we had more complex runtimes; it's a trade-off, and im deciding we have gone too-deep, unleashed monsters, we have perhaps too polarized ourselves against many of the great capabilities we one tried for.
gardenhedge 4y ago
Does SimpleBeanFactoryAwareAspectInstanceFactory not simply spring to your mind when you're coding solutions? /s
- jesuscript 4y ago
  Can you explain what that is or what’s it’s trying to do?

yamtaddle 4y ago

I think some of this is because it's way harder to write a new library for a well-established language & ecosystem and become well-known for it, than it is to do the same in a new ecosystem. This goes for languages and frameworks both—React, for example, generated tons of opportunities like this, to become known for something by basically solving a problem that'd already been solved 1,000 times—but with React. Like, if you want to build your résumé and get offered some of the cushier programming-adjacent gigs and get to present at prominent conferences and generally become A Name, how likely is that to happen if you try to launch some big web framework, or an auth library, or an ORM—in Ruby? Or Java? Nah, too crowded. But if you pick some up-and-coming language (that's up and coming in part because everyone involved is doing exactly what you're trying to do) or hook your wagon to some new framework's (or database's, et c.) hype cycle, well, now you're talking. As a bonus, many of these projects require little or no novelty—it's all well-trod territory. Just half-competently do what hundreds of others have already done, succeed at promoting it (tellingly, this is the harder part) and you're a rockstar. And hell, maybe doing all that does demonstrate some kind of remarkable and valuable skill, for all I know! But the point is, if that's the kind of thing you're trying to do, you need churn, and a bunch of people all trying to accomplish the above drives that very churn. Very little of that activity actually advances the industry, and the churn itself is a huge drag on everything.

r_transpose_p 4y ago

15-25 years ago, there were hip-for-the-time tech influencer bloggers who would write all sorts of stuff about whatever new frameworks and tech were available in the Java world. If you take all the scary Java Enterprise buzzwords in one of the previous posts on this thread, and look them up, you'll find that they all came about, roughly, between 1999 and 2007. I don't fully remember what all the hip influencer tech blogs were during that era (I recall "Joel on Software" having been important), but I do remember that people who paid more attention to such things were really into "Enterprise Java Beans" at the time. So the JVM world might suffer from a bit of an analogous problem. But that world's complexity explosion was decades ago. My feeling is that backend has always been complex, depending on the scale you were trying to operate at (and how much scale your framework and ecosystem forced you to think about whether you wanted to or not). The best you can do to mitigate it is continually ask "Do I really need my backend to handle the scale I'm designing it for?" and "Is all of the complexity in my preferred stack still necessary, or can some of it be hidden/automated?"

jesuscript 4y ago
Heh. So propaganda (or marketing as we now know it) has always worked. When are we ever going to get hip to that reality?
- r_transpose_p 4y ago
  I try to remember that this decades cool hip software trends might become the next decade's enterprise Java. And that's the outcome for the successful stuff! (Doesn't mean you shouldn't get into it though -- if I'd jumped on enterprise java 20 years ago, I'd probably be richer than I ended up by just working on the software I was interested in)

rektide 4y ago

The response I dont see represented is that we were more ambitious in the past. There were all kinds of negative effects, bad tools & out-of-touch architecting that was begot; we can acknowledge that, certainly. But that almost all representation of Java here so emphatically emphasize only the negatively bias, without recongizing also some of the idealism, hope, & progress is to our loss. We were also trying really cool things with many of these java efforts. Rather than a main() routine that imperatively did everything, there were future-sightes notions that we could have a bunch of ambient systems available & interconnected. OSGI solved some thorny library versioning problems, and as a bonus allowed for a very strongly manageable runtime for modules. EJB brought objects up to a higher level, a greater management tier with more interoperability of objects across instances. We were interested in trying more, in tackling harder problems, that microservice era has masked over, deliberately chosen to ignore. Over time we got more refined forms of many of these systems. Maven calmed much of the ad-hoc madness of Ant. CDI was a more reasonable EJB with event more competent management. JSP kept getting better component libs. OSGi actually was... decent all along, sometimes legit useful. But the idea that Java was absurdly troubled seems to endure & be enormously popular hatred/FUD to spread. The fads of today are exactly the opposite of the better managed more flexible runtime trend, where the JVM keeps rising as a more capable, flexible, malleable, adaptable, controllable way to tackle processes than the processes at an OS level. And certainly, there's a lot of ease we've bought ourselves by doing much much less. Statically compiled binaries are an example of yet another means of doing less, of finding easy routes; powerful simplifications that have greatly eased many folk's lives. Less is great, sure. Isolated container instances with dedicated apps is pretty easy to deal with. But there are still constant undercurrents, pushing us towards more interesting complected runtime arraingements, where virtual machines (not fully virtualized os'es but systems like glassfish or erlang, where many sub-processes are co-resident) come back. The idea of very quick very easy to spawn sub-processes allows for interesting security & modularity, where-as today services are almost all monolithic app servers that have complicated multi-user authentication & authorization concerns. We could make simpler safer software if we had more complex runtimes; it's a trade-off, and im deciding we have gone too-deep, unleashed monsters, we have perhaps too polarized ourselves against many of the great capabilities we one tried for.

gardenhedge 4y ago

Does SimpleBeanFactoryAwareAspectInstanceFactory not simply spring to your mind when you're coding solutions? /s

jesuscript 4y ago
Can you explain what that is or what’s it’s trying to do?