Why Spincast?

We tried a lot of Java web frameworks in the past few years, in addition to the obvious Spring Framework with which we already had a lot of experience. Sadly, there was always a little something we dislike.

The main issue with most of the frameworks out there, in our opinion, is that they are often too opinionated. We are grown-up developers, and we don't like when a framework tells us how things have to be done. We wanted a flexible framework which would allow developers to override pretty much everything, even if that means they would also be able to break everything! We wanted a framework which would feel as much as possible like a library. A framework made to be extensible, from the ground up.

We created Spincast in an attempt to be that flexible framework we were looking for. The core ideology will always stay "Power to the developers". In Spincast, everything is configurable, everything can be tweaked.

What about Spring Framework?

Spring Framework / Spring Boot is by far the most popular Java framework. If you are looking for a framework with a very large community and for which paid support is available, look no further, you will not find anything better! We used Spring a lot before starting Spincast.

The problem we had with Spring, is that we found ourself asking those questions too often:

  • "How can I modify that default behavior?"
  • "How do I configure this component?"
  • "How can this work since I didn't even configure it?"
  • "What does this annotation actually do? Can I tweak its behavior?"

Our experience with Spring Framework is that it tends to be a little bit too magical, it tends to hide implementation details too much so your application is harder to configure and tweak. In the name of "Defaults that are good enough 80% of the time", Spring sometimes seems to favor simplicity over providing full control.

Any real-world application will be part of that 20% requiring a lot of manual tweaking, so why not base it on a framework that favors flexibility and control from the ground up?

Yes, it is very easy to start a new Spring Boot application using their pretty Initializr! But as long as you have developed at least one real application in your life, you know that this kind of simple bootstrapping is smoke and mirrors: you will have to modify/change/replace components at some points or another. You will have to manually control what is actually happening behind the scene.

Also, Spring relies a lot on annotations: that contributes to the "easy to use" aura. But, as we explain here, we are not big fans of annotations.

In the other hand, the very first goal of Spincast is to make modifying anything a borderline trivial task. If you find something that is not easily modifiable and should be, it will be considered as a bug and will be fixed.

Here is how you tweak almost anything in a Spincast application:

  1. You identify the class containing the code you want to tweak and the interfaces this class is bound to in the Guice context.
  2. You extend this class to override/tweak/add anything you need. There are no private methods so sky is the limit here.
  3. In your application's Guice module, you bind your custom implementation.
  4. Done. No magic. No components hard to extend.

Even Spincast's core components can be modified using those simple steps.

In other words, we would say that the main difference between Spring and Spincast is that Spincast favors long term flexibility and control from the ground up, while Spring seems more preoccupied with providing something that is easy to start with.

The choices we made

Java

Haters gonna hate!

Java has a lot of haters, these days. On some forums, you almost feel bad to say you're a fan of the language! But the reality is that there are a lot of happy Java developers out there. Maybe they are discreet simply because they're just comfortable with their tools and don't care to argue?

Java is a mature statically typed language; the JVM is freaking performant, and the library ecosystem is huge! Also, the various IDEs and tools are top notch, they allow a fantastic coding/refactoring experience.

Those who say Java is bloated and too complex, are clearly not aware of the modern frameworks and probably still have in mind the old days of J2EE or the applets disaster. Java may be somewhat verbose, and that's true in some cases, but that is not a bad thing in our opinion: verbosity doesn't necessarily mean "hard to read and understand"... In fact, we find that it is often the opposite! Very compact one-liners full of lambdas are often way harder to understand than a couple lines of explicit anonymous classes. And, anyway, Java now has lambdas. Finally, it is your choice if you prefer to call your variables and methods "ulf" and "create()" instead of "userListFactory" and "createDynamicRouteHandler()". But we, personally, like meaninful names.

We have some experience outside Java too: with Node.js for example. Being able to use one language everywhere is an attractive idea, but Javascript? Javascript ?? TypeScript is an improvement, but the coding experience, even if better than before, is far from the one provided by the various Java tools.

C# and the .NET platform also provide that fantastic coding experience and maturity, but they are too platform centric.

Dependency Injection

Once you've worked with dependency injection, it's hard to go back. To design a whole application using DI may be tricky when you are new to it, but the reward is huge.

Being able to easily access the components you need (by injecting them) and always be sure they are properly initialized? Easy testing? Easy implementation swapping? Yes, please!

Guice is, in our opinion, the best dependency injection library of the Java ecosystem. The way the modules work together, and the fact that almost everything is statically typed, is just fantastic. Actually, the fact that Spincast would be based on Guice from the ground up is probably the very first decision we made.

Configuration over convention

The opposite, convention over configuration, has its benefits. For example, it is easier to be up and running on a project where conventions have been used. There is only one way of doing things, so any project is similar to the other. There is also less boilerplate since some magic is used: "That class name ends with "Controller"? Well, it is now a controller!"

We're not big fans of that kind of magic. We prefer when things are obvious because they have been explicitly configured.

Also, conventions kind of restricts possibilities. "You want to structure a part of your application this way because it makes more sense? I don't think so, sorry dude!". Again, we're grown-up developers and we want the freedom to ajust what we want, to structure our application as we want.

Configuration FTW!

Plain Java code over annotations

Annotations are a double-edged sword. They are simple to use and often convenient, but they also tend to hide logic and make things seem to work automagically. This is sometimes fine, but when you need to understand exactly how things work, or when you need flexibility and control, annotations can be a real pain.

Annotations are also limited in the way they can be used. They don't support Java code so adding logic to them is hard : you can't use if / else conditions, you can't call methods, etc. Some people try to get around this limitation by using some kind of expression language, something like @MyAnnotation("${myVar + 42}")... But this is only a hack : there is no type safety and it feels very unnatural in a Java application.

Annotations are very good at being flags, or at providing basic information about an element. For example, the @Inject or @Override annotations are perfectly fine : they don't hide anything and serve purely as indications. But some frameworks have a tendency to use annotations for pretty much everything, and this is something we do not agree with.

Spincast doesn't use many annotations and will in general favor plain Java code when it's time to configure something. The form validation we suggest is a good example : it is purely based on Java code, not on annotations such as Hibernate validator.

No ORM

We are definitively not fans of ORMs such as JPA/Hibernate. Our experience is that an ORM may seem easy to use with a simple CRUD application, but as soon as you deal with a real-world application, you discover its ugly hidden complexity...

We suggest you carefully read Pro JPA 2 to get an idea of the details you need to know to deal with JPA properly! It is not trivial. There are a lot of corner cases.

Plain SQL is what we suggest, with the help of JDBC utilities. We are not saying plain SQL is always easy, but at least you keep full control over what is going on.

For those reasons, you will probably never see an official Spincast JPA/Hibernate plugin. The community may create one and we will link to it, but we will not support it.

We may consider developing official plugins for sane solutions such as JOOQ or MyBatis at one point, though.

Not asynchronous

The problem with asynchronous code is that it's a lot harder and trickier to get right. Thinking in an asynchronous manner when coding is not natural! It is no coincidence that constructs like promises, generators have been created: they try to make asynchronous coding less painful. The Async/Await pattern is ok, but still hard to get right in some situations.

Don't get us wrong... We do love asynchronous processing at Spincast! We strongly believe that reactive patterns using Message brokers / Queuing are very good approaches in many applications. But the important thing to understand is that the code itself doesn't have to be asynchronous for asynchronous patterns to be implemented! In fact, our opinion is that they are more easy to implement using a synchronous code base.

So Spincast is synchronous, and this is clearly a conscious decision. You may say this is one of the points where Spincast is not "flexible" and will probably never be.

No private methods

There may be some exceptions, but there are practically no private methods in Spincast's core and plugins: the default visibility for methods is protected.

But... Isn't this a bad practice? Shouldn't you hide your implementation details?

Well, it depends.

As we previously said, we're not fans of libraries/frameworks which are too opinionated or that use static components that can't be extended. Developers should always have full control over what's going on! And the "no private methods" decision follows that principle.

More than one time we have encountered a library, or part of a framework, which was doing exactly what we needed except a little something! In those cases, the solution is often to extend the class containing the problematic code and to override a particular method. But many libraries/frameworks make this very difficult by using private visibility for lots of their methods. Yes, we get it: they hide their implementation details! But, doing so, they prevent you from adjusting what you would need. So what do you do then? You hope for a code change from the authors, or you simply stop using that library...

Of course, many libraries try to help you by providing some protected methods, but the choices they made is not always the ones you need!

So, our mantra, once again: "Flexibility / Power to the developers"! In Spincast, there are no private methods, at all. If you override a Spincast method because you have to, it is your responsibility as a developer to adjust your code if the base code changes. But, at least, you can do it.