Drupal Smallcore: Where Do We Start?

There has been increasing amount of discussion about the Smallcore initiative in the Drupal community. Smallcore's purpose is to separate Drupal's CMS capabilities from its core APIs and enhance Drupal's characteristics as a universal web-development framework. While most people agree that some level of change is due, the debate around what exactly should smallcore be is still very active.

Before we dive into the details, I would like to make a disclaimer: I whole-heartedly support smallcore in the aspect of making Drupal core more modular, leaner and streamlined (less one-off, spaghetti code thrown together, please). At the same time, when people talk about substantially higher level of generalization, even "fully generic system" - that scares the heck out of me.

It "scares" me, because I've been intimately familiar with one world that has been promising and delivering "fully generic" APIs and specifications for years now: Java/J2EE. A world where abstraction is taken to a complete extreme: everything is generalized, fully-XML-configured and annotated, but in the end - we just get a platform too messy and too slow for Web site development (disclaimer: I think, Java is brilliant in many other use-cases, just not so much for building web sites). Frameworks like Java Server Faces are both very cumbersome, as well as SLOW. And that with bytecode running in JVM! Imagine interpreted scripting code attempting the same level of abstraction in Drupal.

Balance is Core to Smallcore (no pun intended).

I think we have to be very mindful of the level of generalization we really need. When Ruby On Rails came out of shadows and took industry by storm, the biggest thing it had going for itself, vs. say Java/J2EE, was less abstraction. David Heinemeier Hansson removed a lot of abstraction, implementing meaningful default behaviors instead. As a result development became much easier/faster.

A good example from the Drupal world is jQuery. jQuery has served Drupal wonderfully. The level of integration has grown over the years and the benefits from integration have, in my opinion, far exceeded the inconvenience of being tied to one specific framework. On the other side Drupal still supports "pluggable" theming engine implementation, but how many modules/implementations really use any other theming engine except PHPTemplate? Why do we support the ability to drop-in another theming engine? Do we really need the abstraction we've been carrying for many years now?

Another good example is the content-centric approach to the build-out that has been the core philosophy behind Drupal and has served us well. While the actual implementation of the philosophy has certainly evolved: from Nodes with CCK to a full-blown Fields API, the basic principle and approach is still the same and uniform. We just got better at implementing it. This is an important example: Drupal did not offer support for numerous non-content-centric implementations, it just improved the existing one. Would we have benefited if we could implement several approaches instead?

In smallcore debates you often hear an example of login screen - how it sometimes needs to be "undone" and how the process is hard and painful because authentication API is not flexible enough. OK, but if authentication API is broken, is the solution to allow people build alternative (possibly also broken) authentication APIs or is the solution to fix the Drupal authentication API so it is properly modularized and useful?

The questions stated above, put together, lead to the main question of the smallcore effort: Can we agree that, for now, jQuery, content-centric approach (Fields API), Security system's basic API, PHPTemplate, hook system and possibly several other things are indeed smallcore and don't need further abstraction?

One of the strong forces in the Drupal community has always been the tendency to join forces and fix broken stuff, rather than try create duplicate solutions. Is overly generic core a threat to that force?

What is Core?

One of the main characteristics of creating a successful microkernel/small core implementation is making a crucial decision about what needs to be abstracted and what is essential to the system. Basically - once you take everything out, whatever stays in the core should not be overridden and does not need to be generalized/abstracted-out.

We, at Phase2, have built both some very large, complicated, high-traffic websites using Drupal, as well as two popular Drupal-based products a.k.a. distributions: OpenPublish and Tattler (app). On none of these projects was Drupal's standardization on things like content-centric approach, using Views or exclusive usage of jQuery a problem. On the contrary, these standard approaches have allowed for more streamlined implementation and much shorter delivery time than what would have been possible, if we'd used a more abstract framework. Granted things can always be improved (and that's why we see new Fields API in Drupal7 core), but let's also not forget that there's a genuine set of architectural approaches that make Drupal what it is and why we like it.

So, the million-dollar question is: what are the essential building-blocks that define Drupal as a unique framework, therefore constitute its smallcore (or microkernel or "gecko" or call it whatever you like) and that do not need to be over-ridden or further abstracted, but should be highly optimized for performance and scalability?