4 ms·

The problem is not the framework, it's the mindset of the SD community that tends to mindlessly run after the latest hype, abandoning the previous framework tha

The problem is not the framework, it's the mindset of the SD community that tends to mindlessly run after the latest hype, abandoning the previous framework that everybody embraced 3 years ago.

hurril 3y ago
I don't think that cuts to the core of the problem. Java (and JavaScript) are too weak. The way you make them productive is by emulating strength through a framework; more than one way exists to Rome, however, so there will be differences in how The One True Framework must be.
- misja111 3y ago
  No it's not isolated to languages like Java and Javascript. I've programmed in Scala and Haskell as well, and you see the same phenomenon there as well. It's human nature. 'The grass is always greener on the other side', 'the emperor's new clothes' etc.
  - hurril 3y ago
    The difference in both of those cases are that you can create a micro framework yourself for the few abstractions that you need. (Not saying that you should!) Doing this with Java entails reflection and various other runtime extending toolery, which requires a huge panel of tests because of a lack of ability to type the more difficult aspects. This is certainly not impossible and I have done this many times, but it's not practical and it is not cheap.
- usrbinbash 3y ago
  > Java (and JavaScript) are too weak. No, they are not. People have built, and are still building, amazing products using plain JS. They are also doing so using very simple, lightweight frameworks. Abstractions are useful and can increase productivity. The problem is, abstractions have a diminishing return. Using more and more of them stops being useful, and starts becoming detrimental. But, alas, doing so creates the illusion of productivity, because look at all that code I am writing which doesn't actually solve the business problem, but satisfies the abstraction! Look at how amazingly tall my tech-stack tower is, and nevermind all the SRE hours this monstrosity eats, it's state-of-the-art after all! It also makes people feel very smart, because they learned how all these abstractions work, even though nearly the only application of that knowledge is "how to use these specific abstractions". It also creates moats, which a lot of people seem to like (cue "Looking For Frontend Dev, minimum +6 years experience in framework-that-came-out-last-year" - Joke). And lastly, "big tech" are using these abstractions, so "This-Is-The-Way", and nevermind that these companies exist, and have to solve, a completely different problem space.
  - hurril 3y ago
    Find me one company that uses either of the languages without a framework and you make your point. I'll wait.
    - usrbinbash 3y ago
      Done, the company I work at does in several front end applications. Wow, that didn't take long at all. Also, take a look at this: https://news.ycombinator.com/hn.js https://news.ycombinator.com/hn.js That's the JS that powers this very well known, and very widely used website. It's all of 152 lines, including whitespace. And it uses plain Javascript. It's so small, and so simple, it doesn't even need to be minified. So in conclusion, no, JS isn't "too weak", and neither is Java for that matter, and yes people can and are building great products with plain JS. And I write that as someone who really despises both of these languages.
      - hurril 3y ago
        Bah, cheap and weak. But sure, the hill is yours, strong warrior.
        usrbinbash 3y ago
        So my arguments are pretty damn solid. Glad that's sorted out.
        hurril 3y ago
        No, dear Internet adversary. There is a reason why the framework landscape looks the way it does. You can see proof of my point in every job ad there is and frankly, I'm quite disappointed really. Cool companies and interesting ideas get solved by using 19 century tech, so the technical state of the art remains where it has been since forever. This makes me bitter. I constructed my own DI frameworks in the early 2000:s when I did Java. Trying to find interesting places to work now means that I get to work in new codebases that look exactly the same as they did 15-20 years ago. Why is that? Have we learned nothing? I honestly don't even understand your position here. Are you trying to claim that Java is as useful for a normal team of software developers without using Spring Boot? My first 10 years of Scala, I never even once thought about looking for a lightweight framework for managing shared state, DI and/or configuration management. I'll happily concede that working with ZIO is a dream, however. But it is truthfully not needed the way Spring Boot really is for Java to be modern and useful. Same goes for JavaScript in the browser. It isn't really about the lack of powerful tools at your fingertips, it's that you cannot make them in pure Java. You have to "cheat" but resorting to an emulation layer so that you can apply transforms and abstract lifecycle concept. We called them cross cutting concerns in 2003-2004. As in: how do you correctly (read: typesafely) construct a unit of work, correctly configured, with the correct dependencies and correctly interacting with caches and databases for all the 4000 features? In Haskell, you'll easily solve it with a few functions, the usual combinators and the reader monad. In Java, this is Spring Boot quite literally. You need this stack to traverse ground. Without such a type system and the ability to abstract over functions, you either invent it yourself with tests instead of types and adapters/bytecode weaving/code generation instead of functions and monads or you use a framework. Both work and probably work just as well. Without the framework, you have to make it. And there is a basically 100% proof of this in Job Ads. This is what I am critical of. The fact that you want to win over this because your unmentioned company has several frontends that you claim don't use or invent any frameworks is just weak sauce.
vaylian 3y ago
SD = ?
- marionauta 3y ago
  software development, from the context
- ibz 3y ago
  There memory cards you stick in old cameras, I assume.
atoav 3y ago
The problem isn't even the hype, it is that every problem now needs to take the shape of the framework. No matter how powerful your framework is, it lends itself to certain problems well and to others not so much. If all you have is a hammer everyrhing looks like a nail. So instead of openly thinking about what the best solution would be in terms of architecture, interfaces etc, you try to push things into a framework that may or may not fit the problem at hand. If it does, as long as it does: Great. But to me the answer whether a framework is suited to tackle a specific set of problems is hard to figure out before trying it. Most of the times I tried that answer was: "Yeah you could do that, but it is neither elegant, nor performant and doesn't lead to the UX I aim for. Maybe this is about the type of things I want to do or the type of person I am, but my experience with every framework ever was cool as long as I did basic things and impossible as soon as I tried something more involved. So I stick to microframeworks.
- trommlp 3y ago
  I really enjoy using a microframework and multiple small libraries to build a project instead of a huge, opinionated framework for the reasons you mentioned above. Glueing different interfaces together within my own "business logic" can be arduous sometimes, but the flexibility usually pays of when some new unforeseen requirement comes around the corner. That being said I have settled for this simple setup when it comes to web applications. However its quite interesting how I seem to forget the insight I should have gained from all this framework-back-and-forth when I enter a new problem space and inevitably choose the complex, batteries-included framework. This is why I think there is a use-case for every kind of framework out there. The big ones take the load from your shoulders while you are still learning about the problem. And if you so choose and the circumstances allow it, you can replace it later with some framework that is simpler at its core, but possibly easier to maintain, because you are able to reason about every aspect that made it difficult at the beginning.
austin-cheney 3y ago
Frameworks are largely why I have abandoned doing JavaScript work professionally after more than 15 years. It’s not a question of technology problems but of social problems. It’s fashion for the unprepared and religion for the truly incompetent. I got tired of working with that. Many developers dependent upon frameworks have an extreme fear of original code because they cannot actually program even though that’s their job. This results in some horrid immature behavior. My key realization to move on is a complete loss of understanding the work from the people performing the work. It becomes clear when I would advocate an opinion and the people doing work are utterly incapable of hearing it. This isn’t disagreement, which is healthy, because disagreement takes your thoughts into consideration and balances them against opposing interests. When people stop hearing an opinion outright they have no idea what the opinion is, what it means, and how to articulate a response. When this occurs it’s time to move on because you have moved outside their narrow field of perspective.
- trommlp 3y ago
  I agree to some extent on it being a social problem. But I am not sure that developers are to blame outright. What seems to be unpreparedness or incompetence might just be the result of desperately trying to produce something from incomplete information. That is sometimes the people that request the product are just as bad in communicating what the result should be and it might even change half-way through the process. Its hardly surprising that the result is "horrid". So the root of the "social problem" could be anywhere really. That being said there are definitely cases (as in your last paragraph) where you cannot seem to agree with other developers because your understanding of what makes a developer is just so radically different and you keep talking past each other. I would be surprised if that was not the case in every other conceivable profession, though.

The problem is not the framework, it's the mindset of the SD community that tends to mindlessly run after the latest hype, abandoning the previous framework that everybody embraced 3 years ago.

hurril 3y ago

I don't think that cuts to the core of the problem. Java (and JavaScript) are too weak. The way you make them productive is by emulating strength through a framework; more than one way exists to Rome, however, so there will be differences in how The One True Framework must be.

misja111 3y ago
No it's not isolated to languages like Java and Javascript. I've programmed in Scala and Haskell as well, and you see the same phenomenon there as well. It's human nature. 'The grass is always greener on the other side', 'the emperor's new clothes' etc.
- hurril 3y ago
  The difference in both of those cases are that you can create a micro framework yourself for the few abstractions that you need. (Not saying that you should!) Doing this with Java entails reflection and various other runtime extending toolery, which requires a huge panel of tests because of a lack of ability to type the more difficult aspects. This is certainly not impossible and I have done this many times, but it's not practical and it is not cheap.
usrbinbash 3y ago
> Java (and JavaScript) are too weak. No, they are not. People have built, and are still building, amazing products using plain JS. They are also doing so using very simple, lightweight frameworks. Abstractions are useful and can increase productivity. The problem is, abstractions have a diminishing return. Using more and more of them stops being useful, and starts becoming detrimental. But, alas, doing so creates the illusion of productivity, because look at all that code I am writing which doesn't actually solve the business problem, but satisfies the abstraction! Look at how amazingly tall my tech-stack tower is, and nevermind all the SRE hours this monstrosity eats, it's state-of-the-art after all! It also makes people feel very smart, because they learned how all these abstractions work, even though nearly the only application of that knowledge is "how to use these specific abstractions". It also creates moats, which a lot of people seem to like (cue "Looking For Frontend Dev, minimum +6 years experience in framework-that-came-out-last-year" - Joke). And lastly, "big tech" are using these abstractions, so "This-Is-The-Way", and nevermind that these companies exist, and have to solve, a completely different problem space.
- hurril 3y ago
  Find me one company that uses either of the languages without a framework and you make your point. I'll wait.
  - usrbinbash 3y ago
    Done, the company I work at does in several front end applications. Wow, that didn't take long at all. Also, take a look at this: https://news.ycombinator.com/hn.js https://news.ycombinator.com/hn.js That's the JS that powers this very well known, and very widely used website. It's all of 152 lines, including whitespace. And it uses plain Javascript. It's so small, and so simple, it doesn't even need to be minified. So in conclusion, no, JS isn't "too weak", and neither is Java for that matter, and yes people can and are building great products with plain JS. And I write that as someone who really despises both of these languages.
    - hurril 3y ago
      Bah, cheap and weak. But sure, the hill is yours, strong warrior.
      - usrbinbash 3y ago
        So my arguments are pretty damn solid. Glad that's sorted out.
        hurril 3y ago
        No, dear Internet adversary. There is a reason why the framework landscape looks the way it does. You can see proof of my point in every job ad there is and frankly, I'm quite disappointed really. Cool companies and interesting ideas get solved by using 19 century tech, so the technical state of the art remains where it has been since forever. This makes me bitter. I constructed my own DI frameworks in the early 2000:s when I did Java. Trying to find interesting places to work now means that I get to work in new codebases that look exactly the same as they did 15-20 years ago. Why is that? Have we learned nothing? I honestly don't even understand your position here. Are you trying to claim that Java is as useful for a normal team of software developers without using Spring Boot? My first 10 years of Scala, I never even once thought about looking for a lightweight framework for managing shared state, DI and/or configuration management. I'll happily concede that working with ZIO is a dream, however. But it is truthfully not needed the way Spring Boot really is for Java to be modern and useful. Same goes for JavaScript in the browser. It isn't really about the lack of powerful tools at your fingertips, it's that you cannot make them in pure Java. You have to "cheat" but resorting to an emulation layer so that you can apply transforms and abstract lifecycle concept. We called them cross cutting concerns in 2003-2004. As in: how do you correctly (read: typesafely) construct a unit of work, correctly configured, with the correct dependencies and correctly interacting with caches and databases for all the 4000 features? In Haskell, you'll easily solve it with a few functions, the usual combinators and the reader monad. In Java, this is Spring Boot quite literally. You need this stack to traverse ground. Without such a type system and the ability to abstract over functions, you either invent it yourself with tests instead of types and adapters/bytecode weaving/code generation instead of functions and monads or you use a framework. Both work and probably work just as well. Without the framework, you have to make it. And there is a basically 100% proof of this in Job Ads. This is what I am critical of. The fact that you want to win over this because your unmentioned company has several frontends that you claim don't use or invent any frameworks is just weak sauce.

vaylian 3y ago

SD = ?

marionauta 3y ago
software development, from the context
ibz 3y ago
There memory cards you stick in old cameras, I assume.

atoav 3y ago

The problem isn't even the hype, it is that every problem now needs to take the shape of the framework. No matter how powerful your framework is, it lends itself to certain problems well and to others not so much. If all you have is a hammer everyrhing looks like a nail. So instead of openly thinking about what the best solution would be in terms of architecture, interfaces etc, you try to push things into a framework that may or may not fit the problem at hand. If it does, as long as it does: Great. But to me the answer whether a framework is suited to tackle a specific set of problems is hard to figure out before trying it. Most of the times I tried that answer was: "Yeah you could do that, but it is neither elegant, nor performant and doesn't lead to the UX I aim for. Maybe this is about the type of things I want to do or the type of person I am, but my experience with every framework ever was cool as long as I did basic things and impossible as soon as I tried something more involved. So I stick to microframeworks.

trommlp 3y ago
I really enjoy using a microframework and multiple small libraries to build a project instead of a huge, opinionated framework for the reasons you mentioned above. Glueing different interfaces together within my own "business logic" can be arduous sometimes, but the flexibility usually pays of when some new unforeseen requirement comes around the corner. That being said I have settled for this simple setup when it comes to web applications. However its quite interesting how I seem to forget the insight I should have gained from all this framework-back-and-forth when I enter a new problem space and inevitably choose the complex, batteries-included framework. This is why I think there is a use-case for every kind of framework out there. The big ones take the load from your shoulders while you are still learning about the problem. And if you so choose and the circumstances allow it, you can replace it later with some framework that is simpler at its core, but possibly easier to maintain, because you are able to reason about every aspect that made it difficult at the beginning.

austin-cheney 3y ago

Frameworks are largely why I have abandoned doing JavaScript work professionally after more than 15 years. It’s not a question of technology problems but of social problems. It’s fashion for the unprepared and religion for the truly incompetent. I got tired of working with that. Many developers dependent upon frameworks have an extreme fear of original code because they cannot actually program even though that’s their job. This results in some horrid immature behavior. My key realization to move on is a complete loss of understanding the work from the people performing the work. It becomes clear when I would advocate an opinion and the people doing work are utterly incapable of hearing it. This isn’t disagreement, which is healthy, because disagreement takes your thoughts into consideration and balances them against opposing interests. When people stop hearing an opinion outright they have no idea what the opinion is, what it means, and how to articulate a response. When this occurs it’s time to move on because you have moved outside their narrow field of perspective.

trommlp 3y ago
I agree to some extent on it being a social problem. But I am not sure that developers are to blame outright. What seems to be unpreparedness or incompetence might just be the result of desperately trying to produce something from incomplete information. That is sometimes the people that request the product are just as bad in communicating what the result should be and it might even change half-way through the process. Its hardly surprising that the result is "horrid". So the root of the "social problem" could be anywhere really. That being said there are definitely cases (as in your last paragraph) where you cannot seem to agree with other developers because your understanding of what makes a developer is just so radically different and you keep talking past each other. I would be surprised if that was not the case in every other conceivable profession, though.