You cannot build serious stuff in Java effectively without a framework. Choosing Java is choosing frameworks. The reasons are many, such as: Java programmers know Duplo, presented with Lego they are simply unable; Java is Duplo, presented with Lego problems it is simply unable; even a really competent programmer is simply unable when presented with Lego problems and Java because the one way to make it really productive is through the use of a good framework.
Also: All of this is for reasons I am unable to go in to.
Can you elaborate more? I honestly can't think of a time I have been unable to do what I want in Java without frameworks, but I've obviously not tried to do everything.
Sure. But since the point has to do with how Java compares to alternatives when it comes to needing frameworks in the first place, this doesn't add to your point. It detracts from it.
I'd be happy to consider it. There are a number of good technical and non-technical advantages:
* Strong, mature eco-system
* VM-based so we can easily change OS and/or other dev-ops related params.
* Large hiring pool with lots of experience in it (at least this is the case locally)
* More performant than Python, which would maybe be the next language that hits all three of these points.
Your counter-question also deflects and doesn't answer my original question: what problems can not be solved in Java without frameworks? What are examples of lego problems and duplo problems?
Maybe it's a misreading on my part, but I would interpret a "duplo" language as one I could not even build a framework in, due to a lack of low-level control.
You are answering a different question. Opting for Java is smart, albeit incredibly boring. Doing so is basically choosing to go with Spring Boot, at the same time.
You are going to do that because the Java programmers need it, Java needs it and if you don't, as another writer here said: you'll be writing all the frameworks yourself and at considerable cost.
So hating frameworks and picking Java is a dubious position.
You are basically just saying 'java frameworks are mandatory' and then when people are saying 'I've done java without frameworks' (I am also one of those. I'm not primarily a java programmer, but every time I've used java I have used it without frameworks), you're saying 'nu-uh'. You're not going to convince people out of their own experience this way.
Not really. "I did Java in a serious project without frameworks once" is not a counter to: Java needs frameworks to be generally useful.
I am not trying to convince anyone, I'm stating the case that Java and Java programmers need frameworks in a way that more modern programmming languages don't. And that this is why it looks the way it does. My theory thus explains reality.
Do you have a counter to my claim? As in: do you have many examples of companies now that use Java without having gone with Spring Boot (or basically invented it themselves?)
I did Java for a mindnumbing decade, for god's sake. Then I stayed around the JVM for another decade writing in Scala. But! This is not an argument from authority here, I'm merely trying to add some context here lest you think that I am a .NET warrior or simply hate Java from a C++ distance. I am not.
You forgot "To be generally useful". And as I've stated many times now in this thread: the proof lies in what job ads mention. They _never_ look for Java programmers without Spring Boot.
> If I can write useful software in a language without using frameworks, then said usage is not a non-negotiable requirement.
You are not Java. I can write useful software in Brainf*ck. This does not make BF generally useful. Enough, now.
Considering how many job ads for "entry level position" then go on to list a skillset that describes half an IT department, I'm not sure I would consider using these as a technical argument.
The root parent of this discussion pertains to the value of frameworks. In this context, I am making the claim that Java and Java programmers need frameworks and that hating them is basically misdirected. You are, in effect, blaming the plastic hammer for not working without first turning it into a metallic one.
You can agree with this or not but please direct your answers to the claim I am making and please be honest.
I'm frankly shocked that this is a controversial take and I can honestly say that this has made me understand why Java with Spring Boot as well as JavaScript is so prevalent still. You like it the way it is and probably always will!
I mean: judging by how most of you respond, you've probably also missed to point though so I can never be quite sure.
Yeah I hate this, no one wants to spend time mastering a bespoke buggy ad hoc framework which has zero documentation and continuity outside that project/job. Investing in a dead technology by definition.
Yeah I hate this, no one wants to spend time mastering a bespoke buggy ad hoc framework which has zero documentation and continuity outside that project/job. Investing in a dead technology by definition.
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.
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.
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.
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.
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.
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.
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.
Why? You do you. If you want to use frameworks, that's great. Have fun.
If you re-read my post, you may also discover that I am not argueing against frameworks. I argue against over-using them. I argue against needless towers of abstractions. I argue against projects getting stuck in architecture-astronaut-land and analysis-paralysis, where trying to hammer the business case in shape so it fits the technology used, instead of the other way around as it should be, eats up precious, and expensive developer time. This is what I saw a lot of in Java-Land.
Another beast of the same ilk, only with a slightly different head, is framework-jumping, where people bandwagon to a new shiney new thing, that does something slightly different than what exists already, but requires re-learning entire architectures. Bonus points if this leads to re-writing existing, battle tested code just so it fits a new paradigm. This is what I see alot of in Javascipt-Land.
The fact that people are able, willing, and actually do build cool, valueable and inventive things while trying to minimize the amount of noise between them and their tech-stack, is not something that disappoints me. In fact, this is why I largely transitioned to Go as one of my primary languages. And I get the same feedback from many people in many other companies and roles.
You are missing the point completely here. I am not arguing for or against frameworks. I'm telling you that Java and Java programmers need them, and because of that you are going to have swathes of programmers fighting over which ones to use, the correct way to use them and also over the need to switch from the Apples framework to the Oranges framework because it is obv better.
I want better languages instead of a mediocre one papered over with an emulation layer like Spring Boot.
Why do you think there are so many translation layer efforts for JavaScript? Same reason. Java and JavaScript in and of themselves are weak.
I am going to go out on a limb and claim that all of you that downvote me have completely missed this point.
> The fact that people are able, willing, and actually do build cool, valueable and inventive things while trying to minimize the amount of noise between them and their tech-stack, is not something that disappoints me. In fact, this is why I largely transitioned to Go as one of my primary languages. And I get the same feedback from many people in many other companies and roles.
This is not what people are doing. This is what I (and perhaps you!) want. People are _adding_ things on top of the core language. They need and want more stuff. Not less.
> I'm telling you that Java and Java programmers need them,
Yes, I know, you repeated it often enough. And I keep not sharing that opinion of yours.
> Why do you think there are so many translation layer efforts for JavaScript?
That's a really good question, given how little value many of these add depending on the context they are used in, and how many hoops some of them make developers jump through to do things that would be plain simple using less sophisticated libraries instead of frameworks, or go with plain JS in the first place.
Luckily, I answered that question several times in this thread already, so I don't need to repeat myself :-)
> I am going to go out on a limb and claim that all of you that downvote me have completely missed this point.
Or, and hear me out on this: Maybe the people downvoting completely understand your points, and simply...disagree?
> This is not what people are doing.
Yes, this is what people are doing, which is exactly why things like lightweight JS frameworks and uncluttered languages that come batteries included like Go are being so successful.
I would love for you to disagree, but for that to happen, you have to address the points of my arguments, which none of you have.
The things you in particular mention goes towards my point, not against it. We are probably mostly in agreement when it comes to those.
I know that:
- it is easy to make a tiny framework
- you can do that with both Java and JavaScript
- that the translation layers really don't add much effectively
- that you can program both languages without any library even
I know all this. If you think that you have to tell me this or that I am wrong because of this, then you have missed the train.
You can substitute Java and JavaScript there for ARM assembler. Do you get that?
But if you as the proverbial CTO were to suggest going with assembler, people would (drum roll) use my arguments against you. Assembler needs a lot of Something Else to go on top of it and with it to make it generally useful.
This is not to say that there's anything wrong with it in and of itself. But if you want to address cross-cutting concerns in a project, you are shit out of luck. You would invent a... drum roll... high level programming language to go with it. You would also likely want to have some sort of state management to go with that. And error handling, configuration management, various abstractions such that those become ergonomic to use.
Please tell me you get the point now, because so far... you really haven't. I understand your points, but they are not directed at my point and we do not necessarily disagree about anything.
@hurril the equivalent of frameworks in Haskell, in the context of this discussion, are language extensions. I'd say the situation with those is even worse than the framework fad problem in Java or Javascript.
Language extensions don't suddenly turn compile-time errors into runtime errors like certain reflection-heavy Java frameworks do.
But it's true that there's too many different ways of writing Haskell and that makes it very unapproachable to beginners (considering that the core language is not easy to learn to begin with).
Hmm, not sure what you mean about language extensions. Most language extensions just remove unnecessary restrictions in the language. What are you thinking of?
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.
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.
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.
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.
I tend to stick with the first thing that works and isn't too complex. On the frontend, I stayed with Angular. Tried react, hated the infinite abstractions, came back to Angular. Have been reading about Svelte's pragmatism and simplicity. If it really makes things simpler and allows me to reason about lower level things, I might move to it. Not urgent.
With Node, I stayed with NestJS+typeorm, done, no need to revisit that decision tree. For Golang, I stayed with Echo, I only need it to handle the webserver/api side of things, I build the rest myself, done, no need to explore all the other trends. If I revisit something, it might be 5 years down the line, likely the decision will just be to stay with current tools if they continue to work as expected.
And document it yourself, and maintain it yourself, and build an ecosystem of extension for it yourself, and create video tutorials for it yourself, and ...
A minimalist off-the-shelf framework can go a long way.
I like frameworks that do not do much more than provided by their libraries that get exposed by it. So I can always swap out libraries, or carry a long certain libraries after moving on from the framework.
It all depends on 1) how far away from the off-the-shelf framework you are going (or want to go); and 2) how many of your projects you are using it for.
Ideally, you would want to create a plugin/extension to the framework to do your custom thing. But sometimes -- especially when writing games -- you can end up doing things the framework (engine) was not designed for, so end up having/wanting to implement your own thing.
An extension ecosystem and video tutorials really aren't needed for an in-house framework.
Also, with 3rd party extensions, they tend to be poorly made/maintained, and at most do 80% of what I need. If lucky enough to find an extension that does what I need, then it's likely that 80% of it does things that I don't need, which just adds to the bloat and complexity.
Good frameworks are much better than no framework - they railroad it in a way that keeps your code adhering to clean patterns and doesn't railroad you in such a way that it prevents you from doing everything you want.
Bad frameworks are 10x worse than no framework:
* By railroading you they prevent you from doing legitimate things that you want - usually things the framework creator never anticipated.
* With a nightmare framework you may end up having to debug stacktraces that involve not a single line of code that you wrote. I remember when this used to happen with me in Spring when I misconfigured some XML (a long time ago).
Whenever I see a project using something like this it’s always full of insecure, unmaintainable garbage code. It's not that it's impossible to build a good codebase in vanilla PHP, it's just that the kind of person that wants to do it is typically a mid with an inflated ego thinking they're going to be the next Taylor Otwell.
One of PHP’s key advantages is lower cost of maintenance, and it’s much easier to achieve that by using Laravel or Symfony.
In my experience, this is mostly a JVM issue. When I code in the JVM, I feel like I fight my frameworks and libraries more often than writing actual code. Looking at you in particular, Spring Boot.
I had similar experiences in C#.NET and Python (especially SQLAlchemy), albeit less often and less frustrating.
In Golang, the frameworks and libraries tend to stay out of your way. I feel way more productive.
The trade-off is that I am writing more boilerplate. IMO that is a worthwhile tradeoff, especially since things tend to then be more explicit. More explicit is nice for maintenance anyway.
Also, with how far AI code helpers have come, boilerplate is even less of an issue.
I honestly cannot imagine writing modern .NET without a framework. When was this? Modern .NET(5+) is so easy to write and maintain I feel shocked that someone doesn't like it. And I say that as a person who switched from .NET to Typescript+NestJS recently - .NET was really nice to work with for the most part.
> Frameworks always hinder more than help in the long term, because once you need to make one step sideways they inflict indefinite pain on you.
I read messages like these and I would honestly love an example, because throughout last 5 years I've been doing .NET, I never had a case where a framework was hindering my work. People always use shallow arguments like these, but the reality is that 99% of work is basic CRUD making with sprinkle of business logic/validation. If you do the other 1% of work then sure, but in most competently designed frameworks you can accommodate those cases anyway or you won't use a framework in the first place anyway.
As for mentioned startup style changes in .NET - none of those actually required you to do anything. I've migrated dozens of projects from 3.1 to 7 and I didn't really have an issue with any of them. I worked with projects that used all of the approaches to Startup/Program.cs and I none of them ever really bored me. Is it a slight mental overhead? Maybe. Does it matter long term? Not really.
If you work in a tech stack with established patterns/frameworks/libraries and you invent your own wheel, you can be sure next generation or two of developers will absolutely hate you for it, because really, you can't make a better abstraction than a collective of dozens or hundreds of developers over years.
Same, never matched my experience. Each business is trying to innovate and do something different in order to make money, they always require something that is not quite aligned with the frameworks. Also frameworks do a lot of stuff very mediocre, which is fine for quick demos or PoCs but can’t be the final version of a dev team takes pride in their work.
For instance, in ASP.NET, without trying it out tell me what is the exact HTTP response if I have a route registered like GET /foo/bar and someone makes a HTTP POST /foo/bar/ ???
Will it be a 404, a method not allowed? How is the trailing slash dealt with? Does it count as a different route a to the HTTP spec or does ASP.NET trim it when routing? Will the response be in text/html, text/plain or maybe application/json? I bet 99.999% of .NET devs can’t answer this without trying it out and might actually find out that their own APIs don’t quite react to how they would like to if they could choose. So that’s a framework issue, because you have business logic running there giving your end users a response which you don’t even know about or understand. So now you need to alter this to be consistent with the rest of your API and now you go off the beaten path, configuring some toggles and functions in some layers just to deal with a simple error case. Of course, if you’re a mediocre developer who doesn’t take pride and just goes with whatever the framework does out of the box (hint, it won’t be nice because that default behaviour has to be so generic that it works for websites and rest apis use cases equally ok enough) then sure a framework is the right tool for you, but everyone else is probably better off just using a library approach which gives them 100% control in an obvious and consistent way.
> Each business is trying to innovate and do something different in order to make money
This might be shocking for you but _most_ businesses do not innovate anything. That's how the world works, very few people innovate.
> Also frameworks do a lot of stuff very mediocre, which is fine for quick demos or PoCs but can’t be the final version of a dev team takes pride in their work
Github was written in Rails, I guess by your logic original developers should be ashamed of what they built? Would they be able to deliver something like that if they had some sticks&stones version of an http library built by one guy in the beginning?
> For instance, in ASP.NET, without trying it out tell me what is the exact HTTP response if I have a route registered like GET /foo/bar and someone makes a HTTP POST /foo/bar/ ???
Will it be a 404, a method not allowed? How is the trailing slash dealt with? Does it count as a different route a to the HTTP spec or does ASP.NET trim it when routing? Will the response be in text/html, text/plain or maybe application/json? I bet 99.999% of .NET devs can’t answer this without trying it out and might actually find out that their own APIs don’t quite react to how they would like to if they could choose. So that’s a framework issue, because you have business logic running there giving your end users a response which you don’t even know about or understand.
I'm sorry but this is the most ridiculous comment I've read on HN so far.
Besides that all of those questions are basics that anyone who actually works with the stack will be able to answer easily, how does someone's familiarity of framework X internals define this frameworks usability? How will this differ if I jump into your hand-made solution? How long will it take to find out what happens if I give it an invalid path/method/param? I would even argue that if you write that by hand it will take much, much longer to deliver new features and actually customize than adjusting web framework's behavior that exists for over a decade.
Is it a bad thing that web frameworks have some kind of defaults that you can adjust? Hell, I WANT my web framework to return the same response if you give it a wrong http method on every endpoint, I don't want it to depend on whatever-developer-wrote-that-method-whim.
> Of course, if you’re a mediocre developer who doesn’t take pride and just goes with whatever the framework does out of the box (...) then sure a framework is the right tool for you
So now we define someone as mediocre, because they don't know the internals of the tool they use? Do you know internals of your oven? I guess you're a mediocre cook then. Oh so you can't make ChatGPT yourself? Sorry, you're a mediocre developer, clearly.
You do realize that developer's job is to deliver solutions and solve _business_ problems, not invent the wheel, right? Knowing how to write a quicksort doesn't make you an exceptional worker and that's what you are, a worker, like any other.
> Github was written in Rails, I guess by your logic original developers should be ashamed of what they built? Would they be able to deliver something like that if they had some sticks&stones version of an http library built by one guy in the beginning?
Great example to prove my point. They used a framework to quickly get something out of the door and working, validating the business idea, but later migrated away from it, when they had to build for longevity and turn GitHub from good to great.
> Besides that all of those questions are basics that anyone who actually works with the stack will be able to answer easily
except you by the looks of it ^^
> How will this differ if I jump into your hand-made solution?
Yes I'm calling library functions by typing code with my hands
Overall the rest of your comment is just pitiful and I'm not even going to address your outburst because you can't handle that someone on the internet has a different opinion on frameworks than you do.
> Great example to prove my point. They used a framework to quickly get something out of the door and working, validating the business idea, but later migrated away from it
They started migration 10 years after original release of the product, that's not PoC, that's way past that. Also, nowhere anyone said that they wrote their own framework/libraries or wrote anything from scratch, they migrated to multiple different tech stacks for their designated purposes, they might've very well used established frameworks(and probably did) later on.
I won't comment on the rest of your child-like responses.
> nowhere anyone said that they wrote their own framework/libraries or wrote anything from scratch
God why are you so unbearably narrow minded. Devs who reject frameworks where they can don't write everything from scratch. Good lord, there is so many other ways to develop software other than a plug & play framework. People still use existing libraries and functionalities for every use case imaginable, they just pick them as they need and don't inherit those functions as part of a framework with 21 different layers.
Obviously you can build successful apps with frameworks (just as you can write them without, or with lighter-weight frameworks). The question is always how maintainable it will be. Of course, there's also always survivorship bias if we look at examples of successful apps.
Consider, for example, that there's a famous video by Shopify (now already a couple of years old) where they explain how it took them a year to upgrade Rails. In that whole video, I didn't see anybody even ask the question whether there wasn't something fundamentally wrong if it takes you a year to upgrade one piece of your tech stack - something which has no direct impact on value delivered to customers.
The ASP.NET framework is nice. I had more struggles with Entity Framework, to the point where I regretted not just writing raw SQL for my data access needs.
This was also back in 2019 when I last did serious work in C#, so things might have changed a lot since then.
If you did .NET Core in 2019 then it's still very similar, with many improvements here and there.
From my experience ASP.NET Core and EF Core are very good frameworks, usually the horror starts when developers start building their own framework on top of it, instead of keeping it simple.
I agree with your assessment. In Go a lot of the frameworks are more like big libraries, but it's not so much a plug&play architecture, but a pick&assemble what you need, which is why it feels more out of your way, since you don't inherit vast layers but only pick the services and functionalities which you need.
> Also, with how far AI code helpers have come, boilerplate is even less of an issue.
Couldn't agree more.
With how far on-the-fly code generation powered by LLMs has gotten, the oh-so-dreaded "boilerplate" has become an absolute non-issue, especialy in straightforward, explicit languages with little magic like Go, which naturally lend themselves to this kind of code generation.
Best of both worlds: Explicit instructions and less "magic at a distance", and productivity by getting things done fast.
b) Pretty much by definition, boilerplate written against the standard library of the language, rarely, if ever, requires maintenance. Not sure we talk about the same thing here when using the word "boilerplate", so perhaps you want to clarify?
Not a Golang dev, but from your description Go sounds similar to Clojure in that you can kind choose to build your own framework by just picking and choosing your own libraries, e.g. use library X for routing, library Y for templating, etc.
When I was trying to learn Clojure (several years ago... so this info I likely out of date), my understanding was there was a bit of a rift in the community where half the community preferred the flexibility of picking and choosing libs and the other half felt having a "batteries-included" framework would help the growth/adoption of the language. Also, because there was no "goto" framework the libraries were likely not as battle tested.
I'm using Java and unlike the comments in the adjacent thread, using Java doesn't mandate using Spring Boot. There's a bunch of options these days. Personally I'm using Quarkus. Quarkus, like most frameworks, is just a collection of libraries and those libraries follow a "standard" to future-proof your application to an extent. You can still pick and choose what parts you want to use. Want an ORM? Great, include the optional Hibernate dependency. Need to support OpenId connect? There's a simple extension. Nothing really forces you to use the "official extensions", e.g. we're using ElasticSearch but we're not using the Quarkus extension.
I have plenty of things to criticise about frameworks, but this submission isn't really about frameworks - it's supposed to be a parody about certain enterprise design patterns. I think the joke's a bit stale by now, but it's true that sometimes you do find quite convoluted and overengineered patterns on the JVM (though not nearly as often as jokes would have us believe).
I'll add that I think that the joke about killing your ex-girlfriend is in really poor taste.
87 comments
[ 3.2 ms ] story [ 160 ms ] threadAlso: All of this is for reasons I am unable to go in to.
Being able to solve AoC in it doesn't really matter.
You could make this argument about ruby or python. It is quite different to saying "Java is Duplo, presented with Lego problems it is simply unable"
We do that.
We just call it a SpringStoreBackend.
Write 2000 lines of pure Java storage -> you should have used a framework.
But write 2000 lines of Spring storage -> nothing to see here.
* Strong, mature eco-system
* VM-based so we can easily change OS and/or other dev-ops related params.
* Large hiring pool with lots of experience in it (at least this is the case locally)
* More performant than Python, which would maybe be the next language that hits all three of these points.
Your counter-question also deflects and doesn't answer my original question: what problems can not be solved in Java without frameworks? What are examples of lego problems and duplo problems?
Maybe it's a misreading on my part, but I would interpret a "duplo" language as one I could not even build a framework in, due to a lack of low-level control.
You are going to do that because the Java programmers need it, Java needs it and if you don't, as another writer here said: you'll be writing all the frameworks yourself and at considerable cost.
So hating frameworks and picking Java is a dubious position.
I am not trying to convince anyone, I'm stating the case that Java and Java programmers need frameworks in a way that more modern programmming languages don't. And that this is why it looks the way it does. My theory thus explains reality.
Do you have a counter to my claim? As in: do you have many examples of companies now that use Java without having gone with Spring Boot (or basically invented it themselves?)
I did Java for a mindnumbing decade, for god's sake. Then I stayed around the JVM for another decade writing in Scala. But! This is not an argument from authority here, I'm merely trying to add some context here lest you think that I am a .NET warrior or simply hate Java from a C++ distance. I am not.
Yes, it pretty much is.
Because "needs" implies a non-negotiable requirement. I need to breathe to live. I need to study to learn. I need to open the door to leave the house.
If I can write useful software in a language without using frameworks, then said usage is not a non-negotiable requirement.
> If I can write useful software in a language without using frameworks, then said usage is not a non-negotiable requirement.
You are not Java. I can write useful software in Brainf*ck. This does not make BF generally useful. Enough, now.
Considering how many job ads for "entry level position" then go on to list a skillset that describes half an IT department, I'm not sure I would consider using these as a technical argument.
The root parent of this discussion pertains to the value of frameworks. In this context, I am making the claim that Java and Java programmers need frameworks and that hating them is basically misdirected. You are, in effect, blaming the plastic hammer for not working without first turning it into a metallic one.
You can agree with this or not but please direct your answers to the claim I am making and please be honest.
I'm frankly shocked that this is a controversial take and I can honestly say that this has made me understand why Java with Spring Boot as well as JavaScript is so prevalent still. You like it the way it is and probably always will!
I mean: judging by how most of you respond, you've probably also missed to point though so I can never be quite sure.
I have my own DI (distage), logger, IDL/DML/RPC, test harness... And all that stuff takes less than 20000 LoC.
The async runtime we use (ZIO) has been created by a tiny team.
You are making my point, friend.
It's not dead if one person can control it.
> no one wants to spend time
Precisely, that's why a custom mini-framework with 10k LoC is a better option than a 200K LoC pile of crap.
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.
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.
Wow, that didn't take long at all.
Also, take a look at this: 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.
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.
Both Javascript and Java were invented in 1995, pretty sure that's not in the 19th century: https://en.wikipedia.org/wiki/19th_century
> This makes me bitter.
Why? You do you. If you want to use frameworks, that's great. Have fun.
If you re-read my post, you may also discover that I am not argueing against frameworks. I argue against over-using them. I argue against needless towers of abstractions. I argue against projects getting stuck in architecture-astronaut-land and analysis-paralysis, where trying to hammer the business case in shape so it fits the technology used, instead of the other way around as it should be, eats up precious, and expensive developer time. This is what I saw a lot of in Java-Land.
Another beast of the same ilk, only with a slightly different head, is framework-jumping, where people bandwagon to a new shiney new thing, that does something slightly different than what exists already, but requires re-learning entire architectures. Bonus points if this leads to re-writing existing, battle tested code just so it fits a new paradigm. This is what I see alot of in Javascipt-Land.
The fact that people are able, willing, and actually do build cool, valueable and inventive things while trying to minimize the amount of noise between them and their tech-stack, is not something that disappoints me. In fact, this is why I largely transitioned to Go as one of my primary languages. And I get the same feedback from many people in many other companies and roles.
I want better languages instead of a mediocre one papered over with an emulation layer like Spring Boot.
Why do you think there are so many translation layer efforts for JavaScript? Same reason. Java and JavaScript in and of themselves are weak.
I am going to go out on a limb and claim that all of you that downvote me have completely missed this point.
> The fact that people are able, willing, and actually do build cool, valueable and inventive things while trying to minimize the amount of noise between them and their tech-stack, is not something that disappoints me. In fact, this is why I largely transitioned to Go as one of my primary languages. And I get the same feedback from many people in many other companies and roles.
This is not what people are doing. This is what I (and perhaps you!) want. People are _adding_ things on top of the core language. They need and want more stuff. Not less.
Yes, I know, you repeated it often enough. And I keep not sharing that opinion of yours.
> Why do you think there are so many translation layer efforts for JavaScript?
That's a really good question, given how little value many of these add depending on the context they are used in, and how many hoops some of them make developers jump through to do things that would be plain simple using less sophisticated libraries instead of frameworks, or go with plain JS in the first place.
Luckily, I answered that question several times in this thread already, so I don't need to repeat myself :-)
> I am going to go out on a limb and claim that all of you that downvote me have completely missed this point.
Or, and hear me out on this: Maybe the people downvoting completely understand your points, and simply...disagree?
> This is not what people are doing.
Yes, this is what people are doing, which is exactly why things like lightweight JS frameworks and uncluttered languages that come batteries included like Go are being so successful.
The things you in particular mention goes towards my point, not against it. We are probably mostly in agreement when it comes to those.
I know that: - it is easy to make a tiny framework - you can do that with both Java and JavaScript - that the translation layers really don't add much effectively - that you can program both languages without any library even
I know all this. If you think that you have to tell me this or that I am wrong because of this, then you have missed the train.
You can substitute Java and JavaScript there for ARM assembler. Do you get that?
But if you as the proverbial CTO were to suggest going with assembler, people would (drum roll) use my arguments against you. Assembler needs a lot of Something Else to go on top of it and with it to make it generally useful.
This is not to say that there's anything wrong with it in and of itself. But if you want to address cross-cutting concerns in a project, you are shit out of luck. You would invent a... drum roll... high level programming language to go with it. You would also likely want to have some sort of state management to go with that. And error handling, configuration management, various abstractions such that those become ergonomic to use.
Please tell me you get the point now, because so far... you really haven't. I understand your points, but they are not directed at my point and we do not necessarily disagree about anything.
But it's true that there's too many different ways of writing Haskell and that makes it very unapproachable to beginners (considering that the core language is not easy to learn to begin with).
You need -fdefer-type-errors for that!
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.
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.
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.
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.
With Node, I stayed with NestJS+typeorm, done, no need to revisit that decision tree. For Golang, I stayed with Echo, I only need it to handle the webserver/api side of things, I build the rest myself, done, no need to explore all the other trends. If I revisit something, it might be 5 years down the line, likely the decision will just be to stay with current tools if they continue to work as expected.
However, it is fair to judge such an overuse of the factory pattern as obtuse.
And document it yourself, and maintain it yourself, and build an ecosystem of extension for it yourself, and create video tutorials for it yourself, and ...
A minimalist off-the-shelf framework can go a long way.
I like frameworks that do not do much more than provided by their libraries that get exposed by it. So I can always swap out libraries, or carry a long certain libraries after moving on from the framework.
Ideally, you would want to create a plugin/extension to the framework to do your custom thing. But sometimes -- especially when writing games -- you can end up doing things the framework (engine) was not designed for, so end up having/wanting to implement your own thing.
Also, with 3rd party extensions, they tend to be poorly made/maintained, and at most do 80% of what I need. If lucky enough to find an extension that does what I need, then it's likely that 80% of it does things that I don't need, which just adds to the bloat and complexity.
Good frameworks are much better than no framework - they railroad it in a way that keeps your code adhering to clean patterns and doesn't railroad you in such a way that it prevents you from doing everything you want.
Bad frameworks are 10x worse than no framework:
* By railroading you they prevent you from doing legitimate things that you want - usually things the framework creator never anticipated.
* With a nightmare framework you may end up having to debug stacktraces that involve not a single line of code that you wrote. I remember when this used to happen with me in Spring when I misconfigured some XML (a long time ago).
https://dima.fi/ftframeworks/
One of PHP’s key advantages is lower cost of maintenance, and it’s much easier to achieve that by using Laravel or Symfony.
Component based architecture has simplified so much, compared to the endless permutations of MVC, MVP, MVVM, etc.
I had similar experiences in C#.NET and Python (especially SQLAlchemy), albeit less often and less frustrating.
In Golang, the frameworks and libraries tend to stay out of your way. I feel way more productive.
The trade-off is that I am writing more boilerplate. IMO that is a worthwhile tradeoff, especially since things tend to then be more explicit. More explicit is nice for maintenance anyway. Also, with how far AI code helpers have come, boilerplate is even less of an issue.
I honestly cannot imagine writing modern .NET without a framework. When was this? Modern .NET(5+) is so easy to write and maintain I feel shocked that someone doesn't like it. And I say that as a person who switched from .NET to Typescript+NestJS recently - .NET was really nice to work with for the most part.
https://x.com/dustinmoris/status/1736669433928544602?s=20
I read messages like these and I would honestly love an example, because throughout last 5 years I've been doing .NET, I never had a case where a framework was hindering my work. People always use shallow arguments like these, but the reality is that 99% of work is basic CRUD making with sprinkle of business logic/validation. If you do the other 1% of work then sure, but in most competently designed frameworks you can accommodate those cases anyway or you won't use a framework in the first place anyway.
As for mentioned startup style changes in .NET - none of those actually required you to do anything. I've migrated dozens of projects from 3.1 to 7 and I didn't really have an issue with any of them. I worked with projects that used all of the approaches to Startup/Program.cs and I none of them ever really bored me. Is it a slight mental overhead? Maybe. Does it matter long term? Not really.
If you work in a tech stack with established patterns/frameworks/libraries and you invent your own wheel, you can be sure next generation or two of developers will absolutely hate you for it, because really, you can't make a better abstraction than a collective of dozens or hundreds of developers over years.
People always say this and it doesn't match my experience at all. I must be left to conclude that different people live in very different realities.
For instance, in ASP.NET, without trying it out tell me what is the exact HTTP response if I have a route registered like GET /foo/bar and someone makes a HTTP POST /foo/bar/ ???
Will it be a 404, a method not allowed? How is the trailing slash dealt with? Does it count as a different route a to the HTTP spec or does ASP.NET trim it when routing? Will the response be in text/html, text/plain or maybe application/json? I bet 99.999% of .NET devs can’t answer this without trying it out and might actually find out that their own APIs don’t quite react to how they would like to if they could choose. So that’s a framework issue, because you have business logic running there giving your end users a response which you don’t even know about or understand. So now you need to alter this to be consistent with the rest of your API and now you go off the beaten path, configuring some toggles and functions in some layers just to deal with a simple error case. Of course, if you’re a mediocre developer who doesn’t take pride and just goes with whatever the framework does out of the box (hint, it won’t be nice because that default behaviour has to be so generic that it works for websites and rest apis use cases equally ok enough) then sure a framework is the right tool for you, but everyone else is probably better off just using a library approach which gives them 100% control in an obvious and consistent way.
This might be shocking for you but _most_ businesses do not innovate anything. That's how the world works, very few people innovate.
> Also frameworks do a lot of stuff very mediocre, which is fine for quick demos or PoCs but can’t be the final version of a dev team takes pride in their work
Github was written in Rails, I guess by your logic original developers should be ashamed of what they built? Would they be able to deliver something like that if they had some sticks&stones version of an http library built by one guy in the beginning?
> For instance, in ASP.NET, without trying it out tell me what is the exact HTTP response if I have a route registered like GET /foo/bar and someone makes a HTTP POST /foo/bar/ ??? Will it be a 404, a method not allowed? How is the trailing slash dealt with? Does it count as a different route a to the HTTP spec or does ASP.NET trim it when routing? Will the response be in text/html, text/plain or maybe application/json? I bet 99.999% of .NET devs can’t answer this without trying it out and might actually find out that their own APIs don’t quite react to how they would like to if they could choose. So that’s a framework issue, because you have business logic running there giving your end users a response which you don’t even know about or understand.
I'm sorry but this is the most ridiculous comment I've read on HN so far.
Besides that all of those questions are basics that anyone who actually works with the stack will be able to answer easily, how does someone's familiarity of framework X internals define this frameworks usability? How will this differ if I jump into your hand-made solution? How long will it take to find out what happens if I give it an invalid path/method/param? I would even argue that if you write that by hand it will take much, much longer to deliver new features and actually customize than adjusting web framework's behavior that exists for over a decade. Is it a bad thing that web frameworks have some kind of defaults that you can adjust? Hell, I WANT my web framework to return the same response if you give it a wrong http method on every endpoint, I don't want it to depend on whatever-developer-wrote-that-method-whim.
> Of course, if you’re a mediocre developer who doesn’t take pride and just goes with whatever the framework does out of the box (...) then sure a framework is the right tool for you
So now we define someone as mediocre, because they don't know the internals of the tool they use? Do you know internals of your oven? I guess you're a mediocre cook then. Oh so you can't make ChatGPT yourself? Sorry, you're a mediocre developer, clearly.
You do realize that developer's job is to deliver solutions and solve _business_ problems, not invent the wheel, right? Knowing how to write a quicksort doesn't make you an exceptional worker and that's what you are, a worker, like any other.
Great example to prove my point. They used a framework to quickly get something out of the door and working, validating the business idea, but later migrated away from it, when they had to build for longevity and turn GitHub from good to great.
> Besides that all of those questions are basics that anyone who actually works with the stack will be able to answer easily
except you by the looks of it ^^
> How will this differ if I jump into your hand-made solution?
Yes I'm calling library functions by typing code with my hands
Overall the rest of your comment is just pitiful and I'm not even going to address your outburst because you can't handle that someone on the internet has a different opinion on frameworks than you do.
They started migration 10 years after original release of the product, that's not PoC, that's way past that. Also, nowhere anyone said that they wrote their own framework/libraries or wrote anything from scratch, they migrated to multiple different tech stacks for their designated purposes, they might've very well used established frameworks(and probably did) later on.
I won't comment on the rest of your child-like responses.
God why are you so unbearably narrow minded. Devs who reject frameworks where they can don't write everything from scratch. Good lord, there is so many other ways to develop software other than a plug & play framework. People still use existing libraries and functionalities for every use case imaginable, they just pick them as they need and don't inherit those functions as part of a framework with 21 different layers.
Consider, for example, that there's a famous video by Shopify (now already a couple of years old) where they explain how it took them a year to upgrade Rails. In that whole video, I didn't see anybody even ask the question whether there wasn't something fundamentally wrong if it takes you a year to upgrade one piece of your tech stack - something which has no direct impact on value delivered to customers.
This was also back in 2019 when I last did serious work in C#, so things might have changed a lot since then.
From my experience ASP.NET Core and EF Core are very good frameworks, usually the horror starts when developers start building their own framework on top of it, instead of keeping it simple.
Couldn't agree more.
With how far on-the-fly code generation powered by LLMs has gotten, the oh-so-dreaded "boilerplate" has become an absolute non-issue, especialy in straightforward, explicit languages with little magic like Go, which naturally lend themselves to this kind of code generation.
Best of both worlds: Explicit instructions and less "magic at a distance", and productivity by getting things done fast.
b) Pretty much by definition, boilerplate written against the standard library of the language, rarely, if ever, requires maintenance. Not sure we talk about the same thing here when using the word "boilerplate", so perhaps you want to clarify?
When I was trying to learn Clojure (several years ago... so this info I likely out of date), my understanding was there was a bit of a rift in the community where half the community preferred the flexibility of picking and choosing libs and the other half felt having a "batteries-included" framework would help the growth/adoption of the language. Also, because there was no "goto" framework the libraries were likely not as battle tested.
I'm using Java and unlike the comments in the adjacent thread, using Java doesn't mandate using Spring Boot. There's a bunch of options these days. Personally I'm using Quarkus. Quarkus, like most frameworks, is just a collection of libraries and those libraries follow a "standard" to future-proof your application to an extent. You can still pick and choose what parts you want to use. Want an ORM? Great, include the optional Hibernate dependency. Need to support OpenId connect? There's a simple extension. Nothing really forces you to use the "official extensions", e.g. we're using ElasticSearch but we're not using the Quarkus extension.
I'll add that I think that the joke about killing your ex-girlfriend is in really poor taste.
Some more discussion just 5 months ago: https://news.ycombinator.com/item?id=36637655