Are you tired of Java Frameworks Yet?
I know I am. From Spring, Hibernate, React, Angular and having lived through Struts and countless other frameworks that are supposed to make your life easier, I find myself longing for the simplicity of good old C code starting with ‘main’. No fuss, no hidden framework code, No run time generated bytecode, no need to fight with auto generated SQL , no need to learn yet another way to dispatch web requests to your server code.
I’m sure others have reached similar conclusions — Frameworks are simply evil. Once you are past ‘Hello World’ application, and you want to customize the Framework to make it do what you want, you are onto never ending search sessions on Google and StackOverflow. Replace Frameworks with high quality libraries and you call into libraries instead of Framework calling into your code. IMO, that is a much better model to follow for Software development since now you are in full control. Far easier to replace a library than a Framework. No need to figure out the lifecycle and intricacies of the Framework. You see your flow because you wrote it! Don’t like Jackson for JSON processing? No problem — replace it with GSON. On the other hand, your Framework might come bundled with Jackson and now you have two libraries doing the same thing. It’s not only un-necessary to carry two different dependencies for the same functionality, it causes confusion and bloat in the deployed artifact.
Let me illustrate with an Example. I was recently struggling with Postgres auto increment Sequences and corresponding Hibernate implementation. Common sense would dictate Hibernate use separate sequence per table (which is generated by Postgres automatically). But, it turns out, Hibernate uses a single Global Sequence for all auto generated keys across all tables! Maybe there is a good reason for Hibernate developers to have chosen that strategy but it’s moronic nonetheless. Caused me few hours to find this non-intuitive behavior. Then there is the issue of N+1 query with any ORM. The generated SQL is hard to debug and read and even harder to customize. The bloat caused by JPA and Hibernate is simply not worth it. I would say forget Hibernate, JPA etc and simply use JDBC. Horrific as it may sound to young developers, it’s not hard to write SQL — you know exactly what you are fetching from the database, you have full control over SQL and customizations are a breeze. Not to mention you avoid the run time overhead of Hibernate. Remember, you are paying the run time overhead price each time you boot up you application and it adds up rather quickly.
How about Spring? Do you really need all the bloat? I would say 99% of developers need only two features of Spring: DI and property loading. I would advise to ditch Spring altogether , pick a mature DI library like Guice and write your own Properties Loader - loading Properties from few stacked properties files is not that difficult and can be done in an afternoon session of coding. Microservices with HTTP can easily be written using something like Spark and Vertx (although not a library, it’s easy to understand and reason about). If your Microservice doesn’t expose a large number of endpoints, using Netty’s pipeline architecture to serve requests is quite elegant and is not much different than other micro frameworks like Rack.
If you must use a microservices framework, look at newer frameworks like Quarkus which have smaller footprint and do not perform mysterious byte code manipulations. Quarkus is also more cloud friendly than Spring and seems more modularized.
Then there is React (and Angular). Not many developers really understand what goes on under the hood of these frameworks. You need to jump through hoops just to handle Back buttons and Form POSTs. You need a host of tools just to compile and build (Babel, WebPack, nodejs, gulp..). You don’t need this complexity 99 percent of the time. Keep it simple with jQuery, Bootstrap and simple templating like Freemarker. Ditch SPAs altogether. Web and HTTP was not designed to do SPA. Follow few simple rules : each Page is an unique resource with unique URL, POSTs should be followed by redirects to GETs, do not use GETs to mutate state. Most of us do NOT need to trade code simplicity for Virtual DOM.
Last but not the least, do not treat your build and CI toolset as bastardized child of your development process. Stop writing ‘scripts’ to achieve your CI goals. Every Build step and Task should be written in Java/Kotlin as Gradle tasks or Gradle plugins. The ‘buildSrc’ directory in any gradle project is a simple and effective way to write Gradle plugins and that should alleviate any need to cook up bash scripts, gulp tasks and anything else that uses toolsets outside of your development stack. There is no reason to stop using Java when it comes to build and deploys.
The liberating feeling you get when you ditch all the un-necessary complexity is amazing.