Welcome the new Core Team!
A new year has arrived, one that comes with a lot of exciting news for Sane Stack. People are starting to take notice of the project and the feature set is continuously growing. It has now reached a level of complexity that calls for structure, clarity and good planning to ensure success. I am happy to introduce the two new members of our core team. Martin Genev (@cyberseer) the author of 100percentjs.com, Senior Fullstack Developer of classmates.com and co-founder of geminiconnect.com. Kris Williams (@kris_will), with an impressive range of experience having been Lead Developer at Disney, Senior Developer at myspace and now working at his own startup, creativegig.com, utilising Sane Stack.
Our first core meeting was at the end of the year and in an open fashion we are going to utilise this blog to open up our plans and the development to everyone.
This is a curated document about different frontend-/backend-/fullstack solutions underlining my point:
Most of these stacks are based on Angular, with slightly different nuances, a slightly different folder structure and a different backend. Some choices are left to the user but ultimately these stacks have very closely related goals.
Imagine you want to write your first JS fullstack app. You are carefully trying to evaluate which tools to use. Just taking a look at the document mentioned above shows how confusing and tedious this can be. Or perhaps you have already made your choice of stack but alternatives are released, insisting that they offer slightly different or more effective functionality. How do you find the best practices in the midst of this jungle? How do make sure you are getting structured code, the best packages for testing, authentication, frontend styling, etc. without having to spend hours sifting through all these options? What if you work with other people who use their own slightly different stacks? This makes it harder not only for consistency between projects but also in terms of collaboration - developers have to spend energy and time learning which specific choices you made.
Both frameworks are founded on shared principles, ensuring that you don’t have to spend your time curating all these tools and practices. Instead you can start developing your new app with the confidence that other people will find it easier to understand your code and you yourself will have an easier job of maintaining multiple projects with consistent conventions. Additionally, as apps are more than mere coding or prototyping, we are planning to offer the simplicity of a single command to test, secure and deploy your apps.
One thing to note: you will be able to choose to exchange certain parts if you have a very strong, differing opinion, e.g. you want to use another database, another testing framework or another deployment solution. We will keep everything open through a modular system with a set of choices made for you.
This post turned out to be a bit longer than originally planned, so stay tuned for the next one to read about our first meetings and our plans for the future!