templates.about.html Maven / Gradle / Ivy
Show all versions of spincast-website Show documentation
{#==========================================
About
==========================================#}
{% extends "./layout.html" %}
{% block sectionClasses %}about{% endblock %}
{% block meta_title %}About{% endblock %}
{% block meta_description %}Information about Spincast / Philosophy / Team{% endblock %}
{% block scripts %}
{% endblock %}
{% block body %}
{#==========================================
Why Spincast?
==========================================#}
Why Spincast?
A lot of modern Java web frameworks have emerged in the past few years.
We needed one for a project, so we tried a lot of them! Sadly, there was always a
little something we dislike... Some are based on lots of static methods: they seek
to be as simple to use as possible, but doing so they lose flexibility, extensibility, and testability.
Some others force you to use this or that library to do a particular task,
which we found annoying. Also, many use the infamous new keyword everywhere,
and this hurts fans of dependency injection, like us.
But the main problem we had with most of the frameworks out there, is that they
are often too opinionated. We're 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.
Of course, it is still young and will need improvements when new real life use
cases emerge. But the core ideology will always stay "Flexibility / Power to the developers".
Suggestions and
contributions to help improve
Spincast are very welcome!
{#==========================================
The choices we made
==========================================#}
The choices we made
{#==========================================
The choices we made / Java
==========================================#}
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 verbosity almost as much as we hate buzzwords and hyped technologies.
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.
{#==========================================
The choices we made / Dependency Injection
==========================================#}
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.
{#==========================================
The choices we made / Configuration over convention
==========================================#}
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!
{#==========================================
The choices we made / Not asynchronous
==========================================#}
Not asynchronous
There are some situations where asynchronous code is clearly the way to go. If you work on
the Walt-Mart website or if your site really gets millions of requests per minute,
you better make sure your threads don't block, or you'll probably have some problems. But, in our
experience, 95% of the web applications are perfectly fine with synchronous code!
Even quite big applications.
The problem with asynchronous applications is that they are a lot harder
to develop and trickier to get right. Thinking in an asynchronous manner is not
natural! It is no coincidence that constructs like
promises,
generators
and many libraries like async have been
created: they try to make asynchronous coding less painful.
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.
{#==========================================
The choices we made / Private methods
==========================================#}
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.
{#==========================================
Contact
==========================================#}
Contact
If you want to contact us privately (without using the forum),
you can send an email to Julien Lamarre,
Spincast lead developer. Click Here to get Julien's email address.
{% endblock %}